What browsers do for overlapping navigations/history traversals

[domenic]

Consider sequences of two operations from the set { cross-document navigation, same-document navigation, cross-document history traversal, same-document history traversal }, both requested synchronously. (Although all traversals and cross-document navs do not actually finish synchronously.) E.g.

// cross-document nav, cross-document nav
location.search = "?1";
location.search = "?2";

// Assume our history list looks like [?1, ?1#2]
// same-document traversal, cross-document nav
history.back();
location.href = "?3";

What does the spec say should happen here? What do browsers do? I have written a bunch of web platform tests and found out the following things.

This is largely a superset of #6773 which has some previous discussion.

In what follows, XDN = cross-document navigation, XDT = cross-document traversal, and similarly for SDN and SDT. ✔ means "matches the spec", ? means "not yet tested"

First operation	Second operation	Spec result	Firefox result	Chrome result	Safari result
XDN	XDN	Second nav cancels first nav	✔	✔	✔
XDN	XDT	Traversal cancels nav	✔	✔	✔
XDN	SDN	SDN happens synchronously first, then XDN	✔	✔	✔
XDN	SDT	Traversal cancels nav	Traversal ignored; nav wins	✔	Traversal ignored; nav wins
XDN	window.stop()	Nav is canceled	✔	✔	✔
XDT	XDN	XDT and XDN race	XDN gets ignored (even if the XDT is very slow)	XDN gets ignored (even if the XDT is very slow)	XDT gets ignored (even if the XDN is very slow)
XDT	XDT	Traversals queued, but what "back"/"forward" means is computed sync	Ignore second XDT	Coalesce into a single XDT (which could go nowhere or could go +/-2)	Ignore first XDT
XDT	SDN	SDN un-queues all traversals and proceeds	For fragment SDN: queue up traversal after SDN; for pushState SDN: XDT gets stopped	SDN is ignored, XDT succeeds	Queue up traversal after SDN
XDT	SDT	Traversals queued, but what "back"/"forward" means is computed sync	Ignore second SDT	Coalesce into a single XDT (going +/-2)	Somehow the outer page gets reloaded??
XDT	window.stop()	Un-queue the traverals	stop() ignored	stop() ignored	stop() ignored
XDT	browser stop	Un-queue the traverals	?	✔	?
SDN	XDN	SDN completes sync, XDN then proceeds	✔	✔	✔
SDN	XDT	SDN completes sync, XDT then proceeds	✔	✔	Somehow the outer page gets reloaded??
SDN	SDN	SDN completes sync, second SDN completes sync	✔	✔	✔
SDN	SDT	SDN completes sync, SDT then proceeds	✔	✔	✔
SDN	window.stop()	SDN completes sync, stop() is too late so does nothing	✔	✔	✔
SDN	browser stop	SDN completes sync, stop is too late so does nothing	✔	✔	✔
SDT	XDN	XDN can cancel SDT if the SDT takes too long; otherwise it happens after the SDT	✔? SDT is too fast to be sure.	✔? SDT is too fast to be sure.	✔? SDT is too fast to be sure.
SDT	XDT	Traversals queued, but what "back"/"forward" means is computed sync	Traverals queued, e.g. hashchange then load	Traverals queued, e.g. hashchange then load	XDT is ignored
SDT	SDN	SDN un-queues all traversals and proceeds	For fragment SDN: queue up traversal after SDN; for pushState SDN: SDT gets stopped	SDN is happens, but then SDT goes back to the entry computed when the back() call was made	Queue up traversal after SDN
SDT	SDT	Traversals queued, but what "back"/"forward" means is computed sync	Traverals are queued up and happen in order	Second SDT is ignored	First SDT is ignored
SDT	window.stop()	Un-queue the traveral	stop() ignored	stop() ignored	stop() ignored
SDT	browser stop	Un-queue the traveral	? (hard to test for humans)	? (hard to test for humans; we may avoid showing the browser stop button entirely to avoid flicker)	? (hard to test for humans)

Presumably the next step, as with everything in the great history rewrite project, is for @jakearchibald to try to find a model that (a) makes some theoretical sense; (b) matches as many browsers in as many cases as we can.

Some tentative notes:

• Firefox not treating fragment SDNs the same as pushState() SDNs seems bad
• Nobody agrees with the spec's idea that history.back() and history.forward() should compute their destination synchronously.
• It is attractive to go for simple variants like "everything queues", or "everything cancels ongoing stuff", or "everything is ignored if there is ongoing stuff". But that doesn't seem to match any browsers so is probably too risky :(.
• What should history.back() do when sync navigations are involved? #6773 has notes about a model where SDTs and XDTs queue in separate queues that mostly matches Firefox, inspired by analyzing the SDT SDN case.
• window.stop() is easy enough to fix: window.stop() does not cancel traversal navigations, but the stop button does #6905
• WPTs for browser stop are not possible now but will be one day: Add browsingContext.stop w3c/webdriver-bidi#122

[domenic]

Another case to consider is iframe removal. Presumably in that case all XDNs, SDTs, and XDTs are canceled.

[domenic]

I filed

• https://bugs.webkit.org/show_bug.cgi?id=229762
• https://bugzilla.mozilla.org/show_bug.cgi?id=1728622

on a few behaviors that seem clearly wrong.

Here is a tentative proposal for what the spec should say:

First operation	Second operation	Proposed result	Firefox matches?	Chrome matches?	Safari matches?
XDN	XDN	Second nav cancels first nav	✔	✔	✔
XDN	XDT	Traversal cancels nav	✔	✔	✔
XDN	SDN	SDN happens synchronously first, then XDN	✔	✔	✔
XDN	SDT	Traversal cancels nav	❌	✔	❌
XDN	window.stop()	Nav is canceled	✔	✔	✔
XDT	XDN	XDN gets ignored (even if the XDT is very slow)	✔	✔	✔
XDT	XDT	???	?	?	?
XDT	SDN	Queue up traversal after SDN	✔-ish	❌	✔
XDT	SDT	???	?	?	?
XDT	window.stop()	stop() ignored	✔	✔	✔
XDT	browser stop	Un-queue the traverals	?	✔	?
SDN	XDN	SDN completes sync, XDN then proceeds	✔	✔	✔
SDN	XDT	SDN completes sync, XDT then proceeds	✔	✔	❌ (bug)
SDN	SDN	SDN completes sync, second SDN completes sync	✔	✔	✔
SDN	SDT	SDN completes sync, SDT then proceeds	✔	✔	✔
SDN	window.stop()	SDN completes sync, stop() is too late so does nothing	✔	✔	✔
SDN	browser stop	SDN completes sync, stop is too late so does nothing	✔	✔	✔
SDT	XDN	XDN can cancel SDT if the SDT takes too long; otherwise it happens after the SDT	✔?	✔?	✔?
SDT	XDT	???	?	?	?
SDT	SDN	Queue up traversal after SDN	✔-ish	❌	✔
SDT	SDT	???	?	?	?
SDT	window.stop()	stop() ignored	✔	✔	✔
SDT	browser stop	Un-queue the traveral	✔?	✔?	✔?

The big ??? rows are what to do with multiple traversals. It appears at a very high level we have three behaviors to choose from:

• Ignore first traversal (Safari)
• Ignore second traversal (Firefox)
• Coalesce the traversals, potentially to a no-op (Chrome)

I am going to ask my Chrome colleagues what they think about the rows where Chrome is the odd one out, as well as if they have any strong opinions about the correct behavior for multiple traversals. Thoughts from other browser vendors would be very welcome as well.

[annevk]

For SDT then XDT it seems there's a fourth traversals alternative? I.e., queue in order and do both? No strong opinions from me. @smaug---- @mystor @petervanderbeken might have some.

[domenic]

A few updates:

---

My colleagues have pretty much convinced me that Chrome's behavior for multiple traversals, of coalescing them, is a good idea. The argument is basically that it's almost certainly the right behavior for UI-triggered back button XDT+XDT or XDT+SDT case. That is, if the user presses back twice, then no matter how fast or slow those pages load, they should go back twice. Then, we should just extend that behavior to get consistency everywhere:

• We should behave the same for UI-triggered SDT+XDT or SDT+SDT, even though the problem won't really crop up there since SDTs generally complete faster than users can click a second time.
• We should behave the same between developer-triggered history.back() etc. and UI-triggered back button presses, since having those share the same underlying spec primitives and queues seems like a good idea.

I'd love to discuss this with others and hear if they agree. If I don't hear much I'll go ahead and update the above table proposal.

---

On the same thread, it was pointed out that my original assessment of what browsers do for XDN+SDT was not correct; it was Chrome that has the SDT cancel the XDN, whereas the other two browsers ignore the SDT. I think Chrome's behavior is more correct here because it is consistent with the XDN+XDT case, where all browsers agree that the XDT should cancel the XDN.

I have updated the above table accordingly. That leads to one of the few rows where the proposed spec result only matches 1/3 browsers, but I think it's still the right call.

---

On the same thread, I'm still pushing for Chrome to adopt the Safari/Firefox behavior for SDT+SDN and XDT+SDN. We'll see what my colleagues say.

The above table still reflects the Safari/Firefox behavior for those cases as the proposed spec behavior.

---

Finally, my plan is that once we settle (either by silence or through discussion 😄) the multi-traversal case, I'll update all the web platform tests to match the proposed spec. And then @jakearchibald can hopefully incorporate this into his session history rewrite spec PR.

[domenic]

Current proposal, using coalescing behavior for multiple traversals

First operation	Second operation	Proposed result	Firefox matches?	Chrome matches?	Safari matches?
XDN	XDN	Second nav cancels first nav	✔	✔	✔
XDN	XDT	Traversal cancels nav	✔	✔	✔
XDN	SDN	SDN happens synchronously first, then XDN	✔	✔	✔
XDN	SDT	Traversal cancels nav	❌	✔	❌
XDN	window.stop()	Nav is canceled	✔	✔	✔
XDT	XDN	XDN gets ignored (even if the XDT is very slow)	✔	✔	✔
XDT	XDT	Coalesce	❌	✔	❌
XDT	SDN	Queue up traversal after SDN	✔-ish	❌	✔
XDT	SDT	Coalesce	❌	✔	❌
XDT	window.stop()	stop() ignored	✔	✔	✔
XDT	browser stop	Un-queue the traverals	?	✔	?
SDN	XDN	SDN completes sync, XDN then proceeds	✔	✔	✔
SDN	XDT	SDN completes sync, XDT then proceeds	✔	✔	❌ (bug)
SDN	SDN	SDN completes sync, second SDN completes sync	✔	✔	✔
SDN	SDT	SDN completes sync, SDT then proceeds	✔	✔	✔
SDN	window.stop()	SDN completes sync, stop() is too late so does nothing	✔	✔	✔
SDN	browser stop	SDN completes sync, stop is too late so does nothing	✔	✔	✔
SDT	XDN	XDN can cancel SDT if the SDT takes too long; otherwise it happens after the SDT	✔?	✔?	✔?
SDT	XDT	Coalesce	❌	✔	❌
SDT	SDN	Queue up traversal after SDN	✔-ish	❌	✔
SDT	SDT	Coalesce	❌	✔	❌
SDT	window.stop()	stop() ignored	✔	✔	✔
SDT	browser stop	Un-queue the traveral	✔?	✔?	✔?

Caveats:

• This is all testing synchronous overlapping cases, e.g. history.back(); location.href = "...". Presumably there are cases where a navigation or traversal (especially an XDN/XDT) gets "far enough" that these results stop applying. I haven't tested those cases.
• It's possible some of these behaviors differ based on whether the iframes involved are cross- or same-process. All tests were run on same-origin (thus same-process) iframes.

[domenic]

Update: the navigation and session history rewrite has answers for this, and I think I've converted them all into updated web platform tests in web-platform-tests/wpt#36364.

The most complex case remains the overlapping traversals. I'm not sure I've 100% traced the implications of the rewrite for those cases through; I've asked for help from @jakearchibald and @domfarolino to confirm, as part of the review of that WPT PR. It appears the proposed spec there might not match any implementations in some cases. That's bad, and so we'll keep this issue open to track aligning that. But the spec is significantly better at matching implementations for all other cases.