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

["ASF subversion and git services (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/DELTASPIKE-1382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16861044#comment-16861044 ] 

ASF subversion and git services commented on DELTASPIKE-1382:
-------------------------------------------------------------

Commit 8ff76c7df591d271103f7253451110568d227e82 in deltaspike's branch refs/heads/master from Juri Berlanda
[ https://gitbox.apache.org/repos/asf?p=deltaspike.git;h=8ff76c7 ]

DELTASPIKE-1382: Use window.location.replace() for WindowId redirect.

While assigning window.location directly seems to work well in most of the
cases, it manages to break Browser's back button if certain plugins are
installed.

Signed-off-by: Juri Berlanda <ju...@hotmail.com>


> 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
>            Priority: Major
>             Fix For: 1.9.1
>
>          Time Spent: 20m
>  Remaining Estimate: 0h
>
> 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)