[ https://issues.apache.org/jira/browse/DELTASPIKE-1382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16861047#comment-16861047 ]
Thomas Andraschko commented on DELTASPIKE-1382: ----------------------------------------------- Thanks for the PR! i applied it > 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)