You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@deltaspike.apache.org by "Juri Berlanda (JIRA)" <ji...@apache.org> on 2019/06/05 12:33:00 UTC

[jira] [Created] (DELTASPIKE-1382) ClientWindowRenderMode.CLIENTWINDOW breaks Back button in certain Browser/BrowserPlugin combinations

Juri Berlanda created DELTASPIKE-1382:
-----------------------------------------

             Summary: ClientWindowRenderMode.CLIENTWINDOW breaks Back button in certain Browser/BrowserPlugin combinations
                 Key: DELTASPIKE-1382
                 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1382
             Project: DeltaSpike
          Issue Type: Bug
          Components: JSF-Module
    Affects Versions: 1.9.0
         Environment: 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)
            Reporter: Juri Berlanda


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.

h1. 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")

h1. 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

h1. Expected:

* Browser navigates back to index.xhtml

h1. 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)

h1. 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.

h1. 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




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)