Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
1.9.0
-
None
-
Tomcat 9.0.20
MyFaces 2.3.2
OpenWebBeans 2.0.8
DeltaSpike JSF module 1.9.0
Chrome/Chromium + uBlock Origin (just as one example)
Description
It seems, that certain Browser / BrowserPlugin combinations start behaving weird, if ClientWindowRenderMode.CLIENTWINDOW is used. Known affected combinations are:
- Firefox + Evernote Web Clipper
- Chrome/Chromium + Evernote Web Clipper
- Chrome/Chromium + uBlock Origin
Note: Firefox + uBlock Origin for some reason is NOT affected.
Preconditions:
- A JSF application with DeltaSpike JSF Modulke
- ClientWindowRenderMode.CLIENTWINDOW
- At least two pages (in the following they are referred to as "index.xhtml" and "second.xhtml")
Steps to reproduce:
- Load index.xhtml
- In the same Browser window navigate to second.xhtml - make sure the URL used for navigation does NOT contain dswid and dsrid
- Hit the Back button
Expected:
- Browser navigates back to index.xhtml
Actual (assuming the Browser/BrowserPlugin combination mentioned above):
- Browser stays on second.xhtml same page (Actually, Browser navigates back to second.xhtml without dswid and dsrid and then again to second.xhtml with those paramter, but the user hardly notices that)
Reason / Potential Fix:
This issue is caused by windowhandler.html using window.location = redirectUrl; and can be fixed by replacing that with window.location.replace(redirectUrl);. Referencing https://www.w3schools.com/jsref/met_loc_replace.asp I would say the solution is widely supported.
Further notes:
- I will shortly create a PullRequest on GitHub referencing this issue
- If there is need for it, I'd be happy to provide a minimal project demonstrating the issue
Attachments
Issue Links
- links to
