New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 776274 link

Starred by 1 user

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug



Sign in to add a comment

Calling history.replaceState inside beforeunload event handler produces bad navigation

Reported by arcangel...@gmail.com, Oct 19 2017

Issue description

UserAgent: 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).
 
Cc: a...@chromium.org
Components: -Blink Blink>Loader
Labels: -OS-Mac
Thank you for filing the bug and a clear repro.

I am not certain that this is a bug. Handing over to Loading folks + experts to figure this out.
Components: UI>Browser>Navigation
+Navigation folks

Comment 3 by a...@chromium.org, Oct 23 2017

Cc: clamy@chromium.org creis@chromium.org nasko@chromium.org
+more nav peeps

Comment 4 by a...@chromium.org, Oct 23 2017

BTW this doesn't appear to be Plz related.

Comment 5 by a...@chromium.org, Oct 23 2017

Cc: dcheng@chromium.org
+Daniel who seems interested

Comment 6 by dcheng@chromium.org, Oct 23 2017

This is because we don't block replaceState / pushState in beforeunload...

Comment 7 by a...@chromium.org, 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.

Comment 8 by clamy@chromium.org, 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.
Labels: TE-NeedsTraige-help Needs-Milestone
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..!

Owner: clamy@chromium.org
Status: Assigned (was: Unconfirmed)
Loading triage: clamy@ can you own this bug?
I can have a look this week.

Sign in to add a comment