[Seaside] iOS redirect / rendering problem

Wed Aug 3 17:34:03 UTC 2022

 Problem is caused by a seven year old method that used a window.location.href= to gather device characteristics, like screen size and touch support. Removing that href fixes the problem with iOS. Lots of other & cleaner ways to get the data. 

    On Tuesday, August 2, 2022, 03:23:05 p.m. EDT, Bob Nemec <bobn at rogers.com> wrote:  

  Posted this on Discord (fwiw: I'd really like to see us have this question / answer content on stack overflow).
However, redirectToContinuation: is sent after a callback, not after the Azure redirect. And removing the default application entry in WARenderPhaseContinuation>>processRendering: does not make a difference. It is the post-Azure initialRequest redirect that I have not been able to find. Still digging.

    On Tuesday, August 2, 2022 at 02:53:39 p.m. EDT, Bob Nemec <bobn at rogers.com> wrote:  

  To clarify, I do see the 302 redirect being set, but what I can't see is any material difference in the response content. I am trying to see if not coding the default application in the URL will satisfy iOS, since it is only the default app that is having the issue. So https://ourapplication.com/appname?s_... vs. https://ourapplication.com/?s_... Not looking at it as as fix, but curious to see if it makes a difference.
- WACallbackProcessingActionContinuation>>redirectToContinuation:- WAResponse>>redirectTo:
- WAResponse>>found --> self status: WAResponse statusFound - WAResponse statusFound = 302

    On Tuesday, August 2, 2022 at 02:26:08 p.m. EDT, Bob Nemec <bobn at rogers.com> wrote:  

Hey Karsten,Trying to find the difference between the two responses is where I stuck now: from what I can see they are the same... the normal expected rendered content in each case. Just that in the iOS example, the Seaside redirect that answers the content does not happen. 
And it is also where my Seaside internal knowledge stops: I do not yet know how Seaside triggers each render redirect. I thought it answered a 302 response, but the content I trace shows a 200 / OK response. Once I understand how the redirect is code, I figure I can try changes to make iOS happy.
Bob    On Tuesday, August 2, 2022 at 10:31:36 a.m. EDT, Karsten Kusche <karsten at heeg.de> wrote:  

  #yiv1234992836 body{font-family:Helvetica, Arial;font-size:13px;}Hi Bob,
what’s the content produced by the render-phase that’d initiate the following callback-phase?
Kind RegardsKarsten
— 
Georg Heeg eKWallstraße 22
06366 Köthen

Tel.: 03496/214328
FAX: 03496/214712
Amtsgericht Dortmund HRA 12812

Am 2. August 2022 um 15:40:47, Bob Nemec (bobn at rogers.com) schrieb:

fwiw: looking at WARenderPhaseContinuation>>processRendering: I see the same content for both the iOS and Windows initial request. And I see that with iOS the following WACallbackProcessingActionContinuation does not happen, as it does with Windows... that's where I'm stuck.

Bob
On Saturday, July 30, 2022 at 11:00:00 a.m. EDT, Bob Nemec <bobn at rogers.com> wrote:

Thanks... I set up to do the debugging, and it turns out that the problem also happens with Safari on a mac (but not Chrome). That makes it easier to work with. On an iPhone and iPad the problem happens with any browser. 
Bob 

On Saturday, July 30, 2022 at 10:18:13 a.m. EDT, Karsten Kusche <karsten at heeg.de> wrote:

Hi Bob,
when you plug your iOS device into a USB cable and connect it to a mac, then you can go to Mac-Safari -> debug menu -> 3rd or 4th entry in the menu should be the name of your device. There you can open the debugger on a tab of your iOS Safari and debug everything from the Browser side.
Maybe it helps already.
Kind RegardsKarsten
— 
Georg Heeg eKWallstraße 22
06366 Köthen

Tel.: 03496/214328
FAX: 03496/214712
Amtsgericht Dortmund HRA 12812

Am 30. Juli 2022 um 15:59:56, Bob Nemec (bobn at rogers.com) schrieb:

We're having a problem with physical iOS devices (works fine on Chrome virtual device) where a final Seaside redirect is not happening after an Azure SSO redirect. I'd like to understand what triggers the Seaside redirect: I can see it in normal rendering, but I've never had to dig into it like this before. 
When I log from a non-iOS device I see...1: WAApplication>>handleFiltered: application URL  - self requestContext redirectTo: 'https://login.microsoftonline.com/...'   - redirects back to our app URL with an access token2: WAApplication>>handleFiltered: application URL with MS access token & no _s & _k values   - validate token with Azure   - save user info in new WASession   - finish render3: WAApplication>>handleFiltered: application URL with _s & _k plus callback values like: &2=2160&1=3840&3=false   - WAResponse>>location: application URL with _s & new _k and no callback values 4: WAApplication>>handleFiltered: application URL with _s & _K   - finish render  With iOS step 3 does not happen; I'd like to know what triggers it normally. 
Just to add to the fun, we have a two WAApplication registered. The default application fails on iOS, the other works fine. I can see no obvious difference between the two. 
Thanks for any help (I'll cross post on the the Seaside mailing list and Discord)
Bob Nemec

_______________________________________________
seaside mailing list
seaside at lists.squeakfoundation.org
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
seaside mailing list
seaside at lists.squeakfoundation.org
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
_______________________________________________
seaside mailing list
seaside at lists.squeakfoundation.org
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

  _______________________________________________
seaside mailing list
seaside at lists.squeakfoundation.org
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
  _______________________________________________
seaside mailing list
seaside at lists.squeakfoundation.org
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
  _______________________________________________
seaside mailing list
seaside at lists.squeakfoundation.org
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/seaside/attachments/20220803/7dc534f6/attachment.html>