Broken behavior for back-button after history.pushState() + location.replace()

[Sean Hogan]

To reproduce:

1. Navigate to http://www.webkit.org/
2. Open the Javascript console and enter the following

    history.pushState({}, null, "/blog/");

The address-bar now says http://www.webkit.org/blog/, but the page hasn't changed (expected behavior).

3. Now enter the following

    location.replace("/blog/");

The address-bar now says http://www.webkit.org/blog/, and the page reflects this.

4. Press the back-button. The address-bar now says http://www.webkit.org/, but the page hasn't changed from the "/blog/" contents.

This behavior is also observed in up-to-date Chrome.

[Sean Hogan]

The same broken behavior is also exhibited if step 3 is:

    location.reload()

[Sean Hogan]

A work-around for this issue is to replace step #3 with:

    history.replaceState({}, null, currentURL);
    location.replace(nextURL);

where 
    currentURL = "http://www.webkit.org/" or "/" 
    nextURL = "/blog/"

for the demo given above. 

This work-around can cause a flash of the currentURL in the address bar, and it seems bizarre that this should work while the straight-forward code path fails.

[Sean Hogan]

An almost satisfactory work-around for this issue is to replace step #3 with:

    history.replaceState({}, null, "#");
    location.replace("");

I guess this indicates that identified bug is only an issue when `location.replace(url)` is the precise equivalent of `location.reload()` (and there has been a previous invocation of `history.pushState`.)

[Adam Roben (:aroben)]

*** Bug 93506 has been marked as a duplicate of this bug. ***

[Adam Roben (:aroben)]

See https://bugs.webkit.org/show_bug.cgi?id=93506 for a live test case.

AFAICT this behavior disagrees with the spec and with Firefox.

[Radar WebKit Bug Importer]

<rdar://problem/64537409>