Going back in history more than once causes the page to reload
Reported by
gwynj...@gmail.com,
Jun 21 2016
|
||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.84 Safari/537.36 Example URL: https://gwynjudd.github.io/simple/ Steps to reproduce the problem: 1. Go to the page listed (https://gwynjudd.github.io/simple/) 2. Click the button "one" 3. Click the button "two" 4. Click the button "three" 5. Click the button "back" - note that you will see a message box "back" 6. Click the button "back" again - you will see the same message as before Click OK on the dialog, this time you will also see the message: Do you want to leave this site? Changes you made may not be saved. 7. Click OK or cancel on the dialog - either way the same dialog will appear again. You cannot get past this dialog unless you check the box "Prevent this page from creating additional dialogs" ------ Note that the code for the "back" button is very simple: history.back(); alert('back'); If the "alert" is removed, the problem does not occur. If the "beforeunload" handler is removed, or you check the box "Prevent this page from creating additional dialogs", the page actually does reload. What is the expected behavior? The second time you hit the "back" button, it should display the "back" alert, and go back in history the same as the first time. What went wrong? The page reloaded (or attempted to do so), instead of going back in history. Does it occur on multiple sites: Yes Is it a problem with a plugin? No Did this work before? N/A Does this work in other browsers? No Android embedded webview on Android N Chrome version: 51.0.2704.84 Channel: n/a OS Version: 10.0 Flash Version: Shockwave Flash 22.0 r0 Does not occur in MacOS Safari version 9.1.1 Does not occur in Edge 25.10586.0.0 Does not occur in IE 11.306.10586.0
,
Jun 23 2016
Thanks for taking the time to create such a nice testcase. I don't see this happening in 53.0.2767.4/dev on OSX. For me, this works as you'd expect. Can you download Chrome Canary and see if this is fixed for you too? It should install alongside your regular Chrome. test team, can you see if this was a regression that was fixed?
,
Jun 24 2016
Thanks, Seems to be resolved for me in Version 53.0.2777.0 canary (64-bit) on Windows and also MacOSX
,
Jun 24 2016
Is it possible to find out when 53 would be released as stable?
,
Jun 24 2016
Able to repro the issue on win8 chrome version 51.0.2704.106 Issue seems to be fixed in beta 52.0.2743.4 dev 53.0.2774.3 and canary 53.0.2778.0 Reverse bisect Info: Last Bad build:52.0.2742.0 First Good Build:52.0.2743.0 Bisect tool Info: CHANGELOG URL: https://chromium.googlesource.com/chromium/src/+log/f0dfab0bef147f55d6460b42878ef71d0578cc59..6ed4d4373c5ce4743850df50f94b867240472033 Suspecting the following which might caused the fix: https://chromium.googlesource.com/chromium/src/+/6ed4d4373c5ce4743850df50f94b867240472033
,
Jun 24 2016
Moving this nonessential bug to the next milestone. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jun 27 2016
As pointed out in #5, it seems that this has already been fixed in beta by https://codereview.chromium.org/1931793002: now we do not allow nested message loop which may change the order of messages and easily break state assumptions. The old behavior was there for quite a long time, so I don't think it's a recent regression.
,
Jun 27 2016
|
||||||
►
Sign in to add a comment |
||||||
Comment 1 by gwynj...@gmail.com
, Jun 23 2016