back button skips pages on which replaceState is called
Reported by
kman...@gmail.com,
Sep 22 2016
|
|||||||||||
Issue descriptionSteps to reproduce the problem: 1. Go to http://skwakman.github.io/chromeios/ 2. Click on the 'Go to page 1' link, it will navigate you to 1.html 3. Click on the 'Go to page 2' button. When you click on the button, history.replaceState is called right before a change of location.href to 2.html, changing the hash in the process. 4. Click on the 'Go to page 3' button. Same thing happens as in (3), you'll end up at 3.html. 5. When you arrive at page 3, hit the back button. You should end up at 2.html#3, however on Chrome for IOS you'll end up at index.html, skipping every page on which replaceState was called. What is the expected behavior? What went wrong? Apparently the back button skips pages on which history.replaceState is called. This behaviour is not present on chrome on other platforms. Did this work before? N/A Chrome version: 53.0.2785.116 Channel: stable OS Version: OS X 10.11.6 Flash Version: Shockwave Flash 23.0 r0
,
Sep 25 2016
I think I'm getting the same thing with stable (53.0.2785.116) under Linux x86_64 (Fedora 24). Open http://tikirussy.deviantart.com/art/Mi-go-563205024 in a new tab, then click on the link "Lovecraftian Lore"; the back button will be greyed out. If, however, instead of clicking on "Lovecraftian Lore" you click directly on one of the images the back button *isn't* greyed out and will take you back to the same page.
,
Sep 26 2016
,
Sep 26 2016
Have you seen this type of issues before?
,
Sep 26 2016
We do have some code to prevent history navigations to pages that are redirected to prevent getting stuck on a page when going back would redirect to the same page. I believe what's happening here is that the hash change is resetting our "user has interacted with the page" state, so we're recording the replaceState() navigation as a client redirect, which is causing it to be skipped in the history navigation.
,
Apr 21 2017
,
May 11 2017
,
May 12 2017
,
Jul 10 2017
,
Jul 10 2017
,
Sep 29 2017
,
May 18 2018
This is now fixed in M67 canary/dev after enabling #slim-navigation-manager in chrome://flags.
,
Jun 14 2018
Verified in: App Version: 68.0.344025 beta Devices: iPhone 7 Plus, iPhone 8 Plus, iPad Mini iOS Versions: 10.3.3, 11.4, 11.4.1 beta 2 At Step 5: It Navigates back to previous webpage i.e. end up at 2.html#3. Issue is fixed |
|||||||||||
►
Sign in to add a comment |
|||||||||||
Comment 1 by pmadalla@chromium.org
, Sep 23 2016