Re: Issues with Safari (only MacOSX as it seems) and ClientSideWindowStrategy in DeltaSpike 1.9.3

[Juri Berlanda <ju...@tuwien.ac.at>]

Hello again,

after successfully working around the issue by implementing a "redirect" 
counter in LocalStorage, we finally found an additional clue on what is 
going on: it seems, that Twitter (for reasons beyond my understanding) 
tries to generate and display an AMP site (https://amp.dev/) when a link 
to one of our subpages is posted. This page than seems to run on a 
broken ClientSideWindowStrategy, as it is not allowed to set the Cookie. 
We came to that conclusion, as our workaround basically consists of: 
setCookie(), cookie = getCookie(), if isEmpty(cookie) => 
increaseCounter() else resetCounter(), if counter > 3 => error.

Now, neither do we support AMP, nor do we plan to. Also, from WebServer 
logs we seem to only get this behavior from Safari on MacOSX. The MacOSX 
part may be another of Apple's shenanigans trying to hide the fact, that 
it is actually iOS, as we have proof in form of a screenshot that iOS is 
in fact affected.

We are still investiagating, as we did not yet find a way to 
deterministically reproduce it, but I think we are closing in.

In any case: did anybody experience similar behavior, and if so: does 
anybody have a good workaround at hand?

Cheers,

Juri

On 4/7/21 5:17 PM, Juri Berlanda wrote:
> Hi,
>
> problem is: we don't know what exactly causes it, so its difficult to 
> create such a project. It also seems to be a once-in-a-blue-moon kind 
> of bug - at least didn't find a way to reproduce it deterministically 
> yet. But from logs we are pretty sure only Safari on MacOSX is affected.
>
> We patched deltaspike-jsf-module-impl some time ago adding some 
> logging, and indeed we saw, that getVerifiedWindowIdFromCookie() in 
> ClientSideWindowStrategy returns null, over and over again for what 
> seemed to be the same browser.
>
> I will try to put together a small sample project resembling our 
> setup, but I'm not sure if that will allow to reproduce the bug.
>
> Cheers,
>
> Juri
>
> On 4/7/21 3:06 PM, Mark Struberg wrote:
>> do you have a small sample project on GitHub where we can reproduce it?
>> Then it should be rather easy to debug through.
>>
>> LieGrue,
>> strub
>>
>>
>>> Am 06.04.2021 um 12:56 schrieb Juri Berlanda 
>>> <ju...@tuwien.ac.at>:
>>>
>>> Hi all,
>>>
>>> we are using DeltaSpike 1.9.3 with ClientSideWindowStrategy. We need 
>>> it, because we need a dedicated windowId for each browser tab, and 
>>> target=_blank, and so on, and it seems ClientSideWindowStrategy ist 
>>> the only way to achieve that.
>>>
>>> Now, we have seen endless loops on windowhandler.js originating from 
>>> Safari, where it would:
>>> 1) notice it has no WindowId
>>> 2) request one
>>> 3) get one
>>> 4) not  send it
>>> 5) goto (1)
>>>
>>> Operations didn't like it, but we didn't ever find out how to fix 
>>> it, and we thought it may be some "Startpage tile" feature, so we 
>>> did not really care.
>>>
>>> But since the latest MyFaces upgrade to 2.3.8 we think we see 
>>> increasing amounts of:
>>>
>>> javax.enterprise.context.ContextNotActiveException: WebBeans context 
>>> with scope type annotation @WindowScoped does not exist within 
>>> current thread
>>>
>>> ... and ...
>>>
>>> java.lang.NullPointerException: null
>>> at java.net.URLEncoder.encode(URLEncoder.java:224) ~[?:?]
>>> at java.net.URLEncoder.encode(URLEncoder.java:196) ~[?:?]
>>> at 
>>> org.apache.deltaspike.jsf.impl.util.JsfUtils.encodeURLParameterValue(JsfUtils.java:252) 
>>> ~[deltaspike-jsf-module-impl.jar:1.9.3]
>>> at 
>>> org.apache.deltaspike.jsf.impl.util.JsfUtils.addParameter(JsfUtils.java:144) 
>>> ~[deltaspike-jsf-module-impl.jar:1.9.3]
>>> at 
>>> org.apache.deltaspike.jsf.impl.scope.window.strategy.ClientSideWindowStrategy.interceptRedirect(ClientSideWindowStrategy.java:240) 
>>> ~[deltaspike-jsf-module-impl.jar:1.9.3]
>>>
>>> It is something like UA=Mozilla/5.0 (Macintosh; Intel Mac OS X 
>>> 10_15_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0.1 
>>> Safari/605.1.15 - some newer, some older, but always "Macintosh; 
>>> Intel Mac OS X" and "Safari".
>>>
>>> I am not sure if it is related to MyFaces at all, or if the new 
>>> MyFaces version is just somehow more verbose, or if we just think it 
>>> got more, but actually is just an after-easter-load spike, or what not.
>>>
>>> What seems to happen is though, that Safari for some reason seems to 
>>> break ClientSideWindowStrategy - if on purpose or by accident I 
>>> cannot tell. It is also restricted to Safari, i.e. no other WebKit 
>>> based browser seems to behave this way. We can also say for sure 
>>> this is not a "happens every time", as we did not yet find a way to 
>>> deterministically reproduce it.
>>>
>>> Does anybody have any deeper insight on what is going on? Or did 
>>> anybody face the same issues? Any feedback is very much welcome, as 
>>> we have no idea what is going on here.

Re: Issues with Safari (only MacOSX as it seems) and ClientSideWindowStrategy in DeltaSpike 1.9.3

[Mark Struberg <st...@yahoo.de.INVALID>]

Hi Juri!

Thanks for keeping us informed. Sadly never experienced such an issue. But nowadays my JSF apps are mostly used for inhouse stuff in companies, so unlikely to be used by some iPhone.

LieGrue,
strub


> Am 23.08.2021 um 11:03 schrieb Juri Berlanda <ju...@tuwien.ac.at>:
> 
> Hello again,
> 
> after successfully working around the issue by implementing a "redirect" counter in LocalStorage, we finally found an additional clue on what is going on: it seems, that Twitter (for reasons beyond my understanding) tries to generate and display an AMP site (https://amp.dev/) when a link to one of our subpages is posted. This page than seems to run on a broken ClientSideWindowStrategy, as it is not allowed to set the Cookie. We came to that conclusion, as our workaround basically consists of: setCookie(), cookie = getCookie(), if isEmpty(cookie) => increaseCounter() else resetCounter(), if counter > 3 => error.
> 
> Now, neither do we support AMP, nor do we plan to. Also, from WebServer logs we seem to only get this behavior from Safari on MacOSX. The MacOSX part may be another of Apple's shenanigans trying to hide the fact, that it is actually iOS, as we have proof in form of a screenshot that iOS is in fact affected.
> 
> We are still investiagating, as we did not yet find a way to deterministically reproduce it, but I think we are closing in.
> 
> In any case: did anybody experience similar behavior, and if so: does anybody have a good workaround at hand?
> 
> Cheers,
> 
> Juri
> 
> On 4/7/21 5:17 PM, Juri Berlanda wrote:
>> Hi,
>> 
>> problem is: we don't know what exactly causes it, so its difficult to create such a project. It also seems to be a once-in-a-blue-moon kind of bug - at least didn't find a way to reproduce it deterministically yet. But from logs we are pretty sure only Safari on MacOSX is affected.
>> 
>> We patched deltaspike-jsf-module-impl some time ago adding some logging, and indeed we saw, that getVerifiedWindowIdFromCookie() in ClientSideWindowStrategy returns null, over and over again for what seemed to be the same browser.
>> 
>> I will try to put together a small sample project resembling our setup, but I'm not sure if that will allow to reproduce the bug.
>> 
>> Cheers,
>> 
>> Juri
>> 
>> On 4/7/21 3:06 PM, Mark Struberg wrote:
>>> do you have a small sample project on GitHub where we can reproduce it?
>>> Then it should be rather easy to debug through.
>>> 
>>> LieGrue,
>>> strub
>>> 
>>> 
>>>> Am 06.04.2021 um 12:56 schrieb Juri Berlanda <ju...@tuwien.ac.at>:
>>>> 
>>>> Hi all,
>>>> 
>>>> we are using DeltaSpike 1.9.3 with ClientSideWindowStrategy. We need it, because we need a dedicated windowId for each browser tab, and target=_blank, and so on, and it seems ClientSideWindowStrategy ist the only way to achieve that.
>>>> 
>>>> Now, we have seen endless loops on windowhandler.js originating from Safari, where it would:
>>>> 1) notice it has no WindowId
>>>> 2) request one
>>>> 3) get one
>>>> 4) not  send it
>>>> 5) goto (1)
>>>> 
>>>> Operations didn't like it, but we didn't ever find out how to fix it, and we thought it may be some "Startpage tile" feature, so we did not really care.
>>>> 
>>>> But since the latest MyFaces upgrade to 2.3.8 we think we see increasing amounts of:
>>>> 
>>>> javax.enterprise.context.ContextNotActiveException: WebBeans context with scope type annotation @WindowScoped does not exist within current thread
>>>> 
>>>> ... and ...
>>>> 
>>>> java.lang.NullPointerException: null
>>>> at java.net.URLEncoder.encode(URLEncoder.java:224) ~[?:?]
>>>> at java.net.URLEncoder.encode(URLEncoder.java:196) ~[?:?]
>>>> at org.apache.deltaspike.jsf.impl.util.JsfUtils.encodeURLParameterValue(JsfUtils.java:252) ~[deltaspike-jsf-module-impl.jar:1.9.3]
>>>> at org.apache.deltaspike.jsf.impl.util.JsfUtils.addParameter(JsfUtils.java:144) ~[deltaspike-jsf-module-impl.jar:1.9.3]
>>>> at org.apache.deltaspike.jsf.impl.scope.window.strategy.ClientSideWindowStrategy.interceptRedirect(ClientSideWindowStrategy.java:240) ~[deltaspike-jsf-module-impl.jar:1.9.3]
>>>> 
>>>> It is something like UA=Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0.1 Safari/605.1.15 - some newer, some older, but always "Macintosh; Intel Mac OS X" and "Safari".
>>>> 
>>>> I am not sure if it is related to MyFaces at all, or if the new MyFaces version is just somehow more verbose, or if we just think it got more, but actually is just an after-easter-load spike, or what not.
>>>> 
>>>> What seems to happen is though, that Safari for some reason seems to break ClientSideWindowStrategy - if on purpose or by accident I cannot tell. It is also restricted to Safari, i.e. no other WebKit based browser seems to behave this way. We can also say for sure this is not a "happens every time", as we did not yet find a way to deterministically reproduce it.
>>>> 
>>>> Does anybody have any deeper insight on what is going on? Or did anybody face the same issues? Any feedback is very much welcome, as we have no idea what is going on here.