Navigation API: nullify ongoing navigate event on successful cross-document navigation

[noamr]

Currently per spec, setting the ongoing navigation to "traversal" would abort the navigate event and fire navigateerror (and abort the event's signal).

However, tests like this one say otherwise, and this is not implemented anywhere.

In current implementations, the ongoing navigate event stays dangling, which creates unexpected results when the page is restored from BFCache - the abort signal and navigateerror events fired as a result of the next same-document navigation after being restored from BFCache.

This change makes it so that a succesful "traversal" (cross-document navigation) nullifies the ongoing event and API method tracker, without "aborting" it, making it so that the navigation neither signals success or failure.

Closes #11860

• At least two implementers are interested (and none opposed):
  • Gecko
  • Chromium
• Tests are written and can be reviewed and commented upon at:
  • Un-tentative dangling-navigate-event-after-bfcache-restore.tentative.html web-platform-tests/wpt#58599
• Implementation bugs are filed:
  • Chromium: https://issues.chromium.org/issues/491363838
  • Gecko: https://bugzilla.mozilla.org/show_bug.cgi?id=2024555
  • WebKit: https://bugs.webkit.org/show_bug.cgi?id=310261
  • Deno (only for timers, structured clone, base64 utils, channel messaging, module resolution, web workers, and web storage): N/A
  • Node.js (only for timers, structured clone, base64 utils, channel messaging, and module resolution): …
• Corresponding HTML AAM & ARIA in HTML issues & PRs: N/A
• MDN issue is filed: N/A
• The top of this comment includes a clear commit message to use.

(See WHATWG Working Mode: Changes for more details.)

---

/browsing-the-web.html ( diff )

[noamr]

@farre @jnjaeschke @nt1m

[farre]

This is a small change and would be fairly easy to implement, and it's intention is correct. I'm not sure that it's correct as it is in spec though. We queue a task on the navigation and traversal task source, which is the same queue that we a bit later in the same algorithm queue other things on. Are we sure that clearing the ongoing navigate event before those steps are OK? Or should this be moved to after those? Or should the clearing itself be moved to step 12? In effect what we're saying is that the only thing that's allowed to abort a traverse navigate event is anything that's synchronously reachable from #apply-the-history-step. And maybe that's OK, but it's not at all clear to me that this is the case. Is the test you mention the only indication, or do we have more?

I haven't traced this fully, and I have very limited time before the holiday. Its intent does indeed sound reasonable, but if you want me to look deeper it will have to wait to January. I'll ask around to see if anyone else wants to take a stab at it from the Gecko side.

[noamr]

This is a small change and would be fairly easy to implement, and it's intention is correct. I'm not sure that it's correct as it is in spec though. We queue a task on the navigation and traversal task source, which is the same queue that we a bit later in the same algorithm queue other things on. Are we sure that clearing the ongoing navigate event before those steps are OK? Or should this be moved to after those?

The thing is that "set the ongoing navigation" also queues the "aborting" on the same task source, so we have to do this before that's done. The next things queued on that task source is firing pagehide etc.

If we spec things this way, we have to test that e.g. calling pushState in pagehide doesn't cause navigateerror.

Or should the clearing itself be moved to step 12? In effect what we're saying is that the only thing that's allowed to abort a traverse navigate event is anything that's synchronously reachable from #apply-the-history-step.

apply the history step runs on the session history traversal queue, which is parallel from the document's task queue (effectively the "browser process" in chromium). So aborting and setting the ongoing navigate event has to be done in a task.

And maybe that's OK, but it's not at all clear to me that this is the case. Is the test you mention the only indication, or do we have more?

I am not sure, but that test is a pretty clear indication that current browsers don't call navigateerror before pagehide.
I think that calling navigateerror before pagehide would:

• be unexpected as there is no error
• delay cross-document navigations as more script now runs on unload.

An alternative to the proposed spec is to avoid aborting specifically when deactivating the document or beginning the traverse state, and then clearing the ongoing navigate event when restoring.
This would make pushState inside pagehide invoke navigateerror.

Let's continue this in 2026!

[nt1m]

@basuke @RupinMittal

[noamr]

@farre : early 2026 ping to look at this :)

[farre]

@noamr: sorry for the time this has taken, but this:

This change makes it so that a succesful "traversal" (cross-document navigation) nullifies the ongoing event, without "aborting" it, making it so that the navigation neither signals success or failure.

makes so much sense. We should definitely make this be the way things are.

[noamr]

@noamr: sorry for the time this has taken, but this:

This change makes it so that a succesful "traversal" (cross-document navigation) nullifies the ongoing event, without "aborting" it, making it so that the navigation neither signals success or failure.

makes so much sense. We should definitely make this be the way things are.

Thanks! Can I mark gecko as interested? I will proceed with WPTs etc

[nt1m]

cc @annevk for WebKit too

[farre]

@noamr: I've been looking into if this is something we should do for non-intercepted synchronous (same document) navigations. That would mean that if you don't intercept a non-asynchronous navigation that succeeds, navigatesuccess would always fire, which isn't the case today.