Fragment navigation should use replacement enabled

[annevk]

Fixes #2796.

[annevk]

FYI: I'm not really happy with the language here, but changing "replacement enabled" into a proper flag would be quite a bit of work given how hand-wavy we go about passing it through at the moment. 😟

[domenic]

I haven't checked, but @ForbesLindesay's test at https://github.com/ForbesLindesay/jsdom/blob/3316c3c3126dd7aaa3886d3d274e49343ee82634/test/web-platform-tests/to-upstream/html/browsers/browsing-the-web/navigating-across-documents/fragment-replace.html may be adaptable here, although it's worth noting it fails in Edge and Firefox (but passes in Chrome). I'm not sure if the interop issue it thus reveals is related to this issue, or not.

[domenic]

Well, I've confirmed at least that manually running @ForbesLindesay's test case from the OP of #2796 works the same in Firefox as in Chrome (URL updates to #cat). So I guess it is a different issue; in fact the assert message is pretty helpful, and reveals that history.back() doesn't seem to be async in Firefox.

Which is all to say, maybe there is a simpler test that passes in all browsers and still tests the issue here, that we can extract out of @ForbesLindesay's test case.

[domenic]

Actual text LGTM (modulo build failures).

[annevk]

I can't get there programmatically.

<iframe src=/></iframe>
<script>
onload = () => {
  self[0].location.hash = "t1"
  w(self[0].location.hash)
  self[0].location.hash = "t2"
  w(self[0].location.hash)
  self[0].location.hash = "t3"
  w(self[0].location.hash)
  history.back();
  setTimeout(() => {
    w(self[0].location.hash)
    self[0].location.replace("/#something");
    setTimeout(() => {
      w(self[0].location.hash)
      history.forward();
      setTimeout(() => {
        w(self[0].location.hash);
      }, 200);
    }, 200);
  }, 200);
}
</script>

In Live DOM Viewer does something entirely different in Firefox compared to Chrome. Firefox basically doesn't navigate back or forward.

cc @smaug----

[annevk]

(Build failures fixed btw, apparently forgot to push a fix.)

[domenic]

In my experience testing in live-dom-viewer or similar does not work well because of initial about:blank issues; testing in isolated files I saved to my desktop improved interop a decent bit. Not sure if that's enough to fix things though.

[annevk]

If I add w = al => alert(al); to the above and load it locally I get the same results in Fx and Chrome navigates back to the "New Tab" page after three alerts.

[domenic]

I'll try fiddling around with it tomorrow and see if I can make any progress. (Today I'm off as I've got family visiting.) Worst-case I guess we do a manual test...

[domenic]

A couple weeks later than promised, but I managed to get a test case working at web-platform-tests/wpt#6877. Happy to merge this when you're ready.