Notify WebDriver BiDi about "committed" navigations

[OrKoN]

This PR adds integration with the WebDriver BiDi spec to notify automation sessions when a navigation results in a new document being loaded. See w3c/webdriver-bidi#788 and w3c/webdriver-bidi#855.

• At least two implementers are interested (and none opposed):
  • Chrome
  • Firefox
• Tests are written and can be reviewed and commented upon at:
  • Tests will be written as part of the WebDriver BiDi spec (changes not observable otherwise).
• Implementation bugs are filed:
  • Chromium: Implement navigation committed event GoogleChromeLabs/chromium-bidi#2982
  • Gecko: Request for a navigationCommitted event to inform immediately about the navigation status w3c/webdriver-bidi#788
  • WebKit: https://bugs.webkit.org/show_bug.cgi?id=281932
  • Deno (only for timers, structured clone, base64 utils, channel messaging, module resolution, web workers, and web storage): …
  • 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 )
/infrastructure.html ( diff )

[sadym-chromium]

LGTM

[jgraham]

So in 6.4.1 in attempt to populate the history entry's document (covering the case of navigating to a document without a DOM) seems to run a the navigation failed steps (and so emits a navigation failed event), but the document isn't null in that case so we'll still send the navigation committed event in 7.4. Possibly we need to move emitting this event up into step 6?

[OrKoN]

So in 6.4.1 in attempt to populate the history entry's document (covering the case of navigating to a document without a DOM) seems to run a the navigation failed steps (and so emits a navigation failed event), but the document isn't null in that case so we'll still send the navigation committed event in 7.4. Possibly we need to move emitting this event up into step 6?

Thanks for spotting this. On one hand there is a new document committed by the navigation (that might be relevant for the client), on the other hand the events get confusing (failed, then committed) and IIUC this is about error pages where the only useful action is to reload. I guess moving to 6 would be an option or checking saveExtraDocumentState or document's salvageable state.

[OrKoN]

Moved to step 6.

[OrKoN]

@domenic could you please take a look when you have a chance?

[domenic]

I'm a little worried about this running before the history state is updated. In particular, the active history entry etc. will still be on the old document. Is that OK, in the WebDriver BiDi context?

[OrKoN]

I'm a little worried about this running before the history state is updated. In particular, the active history entry etc. will still be on the old document. Is that OK, in the WebDriver BiDi context?

WebDriver BiDi spec does depend on the history state for this event. In practice, I believe the history state would be completed before the event can be handled by the client. I think it would be great to emit when the state defined in the HTML spec is in the consistent state.

Is the history state usually updated in the completion steps of this algorithm? Should we move the event to after the completion steps are run? What would you recommend?

[domenic]

History state is updated in the monster algorithm apply the history step. Note that that algorithm is called for all history step updates, including traverses and reloads, not just the push/replace navigations you're interested in.

The algorithm you're modifying, "attempt to populate the history entry's document", is called in step 12.8.7 of "apply the history step". It basically does the fetch of the new document, but there are many steps left until we get to what I think of as the actual commit. The completion steps for it don't fully finish updating the history step: instead they enqueue an update which runs later, in step 14. Step 14.10 or 14.11 unloads the previous document, and then after that process is done it does a callback to afterPotentialUnloads.

afterPotentialUnloads (declared in step 14.12) is where things get interesting. By its step 2, the "browser process" is all updated. But the document itself is not yet updated to realize that it's active, necessarily: e.g., its navigation API state is not yet initialized, and same-document navigations or bfcache traversals haven't updated the relevant JS APIs. That happens in update document for history step application.

So I suspect what you want is to insert something either after step 2 of afterPotentialUnloads, if you only care about the "browser process", or at the end of "update document for history step application", if you care about the document's state. The latter sounds safer.

The hardest part will be filtering so that you only do this on cross-document push/replace navigations, but I think the "update document for history step application" algorithm has enough local state that you should be able to do this. (navigationType and documentIsNew should do it, I think.)

[OrKoN]

thanks @domenic It sounds like WebDriver BiDi would be interested in all situations when documentIsNew. I have updated the PR and moved the call to "update document for history step application" before any document scripts may run.

@jgraham could you please take a look at the proposal as well?