Calling history.replaceState inside beforeunload event handler produces bad navigation
Reported by
arcangel...@gmail.com,
Oct 19 2017
|
||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36 Steps to reproduce the problem: I have produced a minimal repro at http://chromebug.stevearc.com/ 1) Create a beforeunload handler that returns a non-null value (so the confirm dialog will appear) and also makes a call to history.replaceState. window.onbeforeunload = function() { window.history.replaceState(1, '', window.location.href); return ''; } 2) After loading the page and interacting, type a different location in the URL bar and navigate away What is the expected behavior? Expected behavior is that Chrome will display a confirmation popup that allows the user to remain on the page or to navigate away What went wrong? Chrome will show the popup, but then navigate away anyway without any user input. Did this work before? N/A Chrome version: 61.0.3163.100 Channel: n/a OS Version: OS X 10.12.6 Flash Version: There are several similar and likely related problems. If you navigate away using a bookmark, it does pause at the modal but will navigate away no matter which option you choose. If you refresh but then select "Don't Reload," the page will still refresh (this one doesn't repro when devtools are open).
,
Oct 23 2017
+Navigation folks
,
Oct 23 2017
+more nav peeps
,
Oct 23 2017
BTW this doesn't appear to be Plz related.
,
Oct 23 2017
+Daniel who seems interested
,
Oct 23 2017
This is because we don't block replaceState / pushState in beforeunload...
,
Oct 23 2017
This demo and Twitter use replaceState to switch the state object without changing the URL. I guess it's kind of a "right before I leave save my state" deal, which doesn't seem like a terrible thing to me.
,
Oct 24 2017
This is very likely due to the hack in DidCommitProvisionalLoad where we consider that a DidCommitProvisionalLoad serves as a BeforeUnload ACK. See https://cs.chromium.org/chromium/src/content/browser/frame_host/render_frame_host_impl.cc?type=cs&q=renderframehostimpl&l=1509. We should remove this hack eventually.
,
Oct 26 2017
Seems it is out of scope from TE end, adding TE-NeedsTraige-help label to move this out of our triaging bucket. Could someone from dev team please take a look into this issue. Thanks..!
,
Dec 5 2017
Loading triage: clamy@ can you own this bug?
,
Dec 5 2017
I can have a look this week. |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by dglazkov@chromium.org
, Oct 23 2017Components: -Blink Blink>Loader
Labels: -OS-Mac