Snapshot fallback base URL for about:-schemed Documents

[domfarolino]

This PR gives an "about base URL" member to:

• Document
• Document state
• Navigation params

The intention is to capture a document's creator's base URL in https://html.spec.whatwg.org/C#creating-a-new-browsing-context and preserve it to (1) the newly created document itself, and (2) the newly-created document state in both:

• https://html.spec.whatwg.org/C#create-a-new-child-navigable; and
• https://html.spec.whatwg.org/#creating-a-new-top-level-traversable

For the navigation case, we capture the initiator's base URL in #navigate as initiatorBaseURLSnapshot alongside initiatorOriginSnapshot. We preserve this to the document state created in #navigate when navigating to about:-scheme URLs, alongside the document state's origin. It is later used in #create-navigation-params-by-fetching and the about:srcdoc case for population of the navigation params's about base URL, so it can be transferred to the actual document in https://html.spec.whatwg.org/C#initialise-the-document-object.

Finally, we remove the concept of a browsing context's https://html.spec.whatwg.org/C#creator-base-url algorithm, and in https://html.spec.whatwg.org/C#fallback-base-url we only reference the new concept-document-about-base-URL member which is a snapshot of the creator/initiator base URL.

There are a few instances of manually-constructed navigation params outside of the normal flow:

• The response-is-null case: https://html.spec.whatwg.org/C#beginning-navigation:navigation-params
• The javascript: URL special case: https://html.spec.whatwg.org/C#the-javascript:-url-special-case:navigation-params
• The inline-content-that-doesn't-have-a-DOM case: https://html.spec.whatwg.org/C#read-ua-inline:navigation-params

As of now this PR passes in null for the navigation params's about base URL in these (not stricken-through) cases above, but I'm not sure if that is correct. I'm looking into it and it is perhaps the one thing blocking this PR at this case.

Closes #421. Closes #2883. Closes #3989.

• At least two implementers are interested (and none opposed):

  • Chrome
  • WebKit: Request for snapshotting initiator base URL WebKit/standards-positions#197
  • Gecko: Snapshotting inherited base URL mozilla/standards-positions#813

• Tests are written and can be reviewed and commented upon at:

  • html/infrastructure/urls/terminology-0
  • html/infrastructure/urls/base-url/
  • CL 4652304

• Implementation bugs are filed:

  • Chromium: https://bugs.chromium.org/p/chromium/issues/detail?id=1356658
  • Gecko: https://bugzilla.mozilla.org/show_bug.cgi?id=1843427
  • WebKit: https://bugs.webkit.org/show_bug.cgi?id=259200
  • 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): …

• MDN issue is filed: …

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

---

/browsing-the-web.html ( diff )
/document-lifecycle.html ( diff )
/document-sequences.html ( diff )
/dom.html ( diff )
/urls-and-fetching.html ( diff )

[domenic]

I suspect http://localhost:8080/#the-javascript:-url-special-case also needs to copy over the about base URL, since that case creates a new document state that replaces the old one, but keeps the URL (which might be something like about:srcdoc or about:blank).

Can you be sure to write tests for that case?

[domenic]

Let's be sure to note when merging this that it closes #421. I think this does not close #2883 or #3989 yet though, right? Or does it? Edit: hmm I think it does. Do we have WPTs for the cases mentioned there?

[domfarolino]

I suspect http://localhost:8080/#the-javascript:-url-special-case also needs to copy over the about base URL, since that case creates a new document state that replaces the old one, but keeps the URL (which might be something like about:srcdoc or about:blank).

Yeah I think you're right. I made two changes: copied the document state member over manually in the algorithm you linked to, and assigned the navigation params's about base URL to the target navigable's active document's about base URL, since this happens in a separate algorithm. I think that should do the trick.

---

Thanks for the review. I'm going to make sure tests get written for:

• The navigate-about-document-to-javascript-URL
• The detached frame case (Fallback base URL for detached IFRAME documents #2883)
• The document.open()-in-about:srcdoc case (Fallback base URL computation for a document with about:srcdoc but not an iframe srcdoc document #3989) (this is done in https://github.com/web-platform-tests/wpt/blob/master/html/infrastructure/urls/base-url/document-base-url-changes-about-srcdoc-2.https.html)

[domenic]

I'm OOO until Tuesday, but I think James already wrote tests for #3989.

[wjmaclean]

Are there document.open() + about:srcdoc scenarios we need to test in addition to document-base-url-changes-about-srcdoc-2.https.html ?

[domfarolino]

Nope I don't think so.

[domenic]

LGTM with one question. Also note my nit fixes.

[domfarolino]

Thanks. OK I think this should be good to go, depending on what our policy for writing WPTs for <object> and <embed> these days (since they are deprecated features that we're tend to not explicitly cater to is my understanding). We can probably write them anyways, but not sure if it is blocking.

[domenic]

Tests for object and embed would be appreciated but definitely not blocking. There are so many interop and spec problems with them, anything in that area is just best-effort.