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

Issue 681372 link

Starred by 3 users

Issue metadata

Status: Untriaged
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 3
Type: Bug



Sign in to add a comment

Browser back button broken after Post-Redirect-Get.

Reported by valer...@gmail.com, Jan 15 2017

Issue description

Chrome Version       : 55.0.2883.87 (Official Build) m (32-bit)
URLs (if applicable) :
Other browsers tested:
  Add OK or FAIL, along with the version, after other browsers where you
have tested this issue:
     Safari: Not tested
    Firefox: OK
         IE: OK
       EDGE: OK

What steps will reproduce the problem?
Build a page at url A with an anchor to url B, that has a form that POST REDIRECT GET to url B and press the back button.
Navigate to url A, press link to url B, Submit the form, press the back button of the browser.

What is the expected result?
You should land to Url A.

What happens instead?
You are still in Url B.

Please provide any additional information below. Attach a screenshot if
possible.

Firefox, IE, Edge behave correctly, and no api in history object allow a developer to work around it.
 

Comment 1 by ajha@chromium.org, Jan 16 2017

Components: UI>Browser>Navigation
Labels: Needs-Triage-M55
Cc: brajkumar@chromium.org
Labels: Needs-Feedback
valeriob@ Thanks for the report, Could you please provide a sample test case of the issue as html or js-fiddle file to triage it from chrome-TE end.

Thanks!

Comment 3 by valer...@gmail.com, Jan 16 2017

You can reproduce it here : 
http://chrome-prg-back.azurewebsites.net/

Click "Go to B", Click Save, Press the browser back button or the link "Back".
In chrome you are still in PageB, in Firefox, IE, Edge you are in Page A (correct behavior).
Project Member

Comment 4 by sheriffbot@chromium.org, Jan 23 2017

Labels: -Needs-Feedback Needs-Review
Owner: brajkumar@chromium.org
Thank you for providing more feedback. Adding requester "brajkumar@chromium.org" for another review and adding "Needs-Review" label for tracking.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Comment 5 by cda...@chromium.org, Mar 13 2017

Cleaning up "Needs-Review" label as we are not using this label for triage. Ref  bug 684919 

Comment 6 by cda...@chromium.org, Mar 13 2017

Labels: -Needs-Review
Labels: -Needs-Triage-M55 M-60 OS-Linux OS-Mac OS-Windows
Owner: ----
Status: Untriaged (was: Unconfirmed)
Able to reproduce this issue on Windows-10, Ubuntu 14.04 and Mac OS 10.12 using chrome latest stable #57.0.2987.133. By opening the test link from comment #3, observed the page is not navigated to Page A from Page B. Able to navigate to Page A after 2 clicks

This issue is observed on chrome older version of #35.0.1849.0 as well, Hence marking it as untriaged.
Hi,
any news on the issue ?
Components: UI>Browser>History
Labels: Hotlist-Interop
Adding Hotlist-Interop since the bug says that Firefox, IE, Edge behave differently.

Copying the html that triggers this bug http://chrome-prg-back.azurewebsites.net/Home/PageB:

    <form method="post">
        <button type="submit" >Save</button>
        <a href="javascript:void(0)" onclick="history.back();">Back</a>
    </form>

I've checked that the same behavior is observed in Chrome after changing the method to GET (well, except that the URL changes to http://chrome-prg-back.azurewebsites.net/Home/PageB?, making it even clearer that a new history/navigation entry was created).


Safari Version 12.0 (13606.2.11) behaves like Chrome (perhaps this is unsurprising, since Chromium's rendering engine Blink has its origins in Safari's WebKit).
yep Safari is on the same boat : https://bugs.webkit.org/show_bug.cgi?id=166965

Sign in to add a comment