Define srcdoc documents as matching about:srcdoc URL

[domfarolino]

Before this PR, the spec defined "an iframe srcdoc document" as being solely constructed from the contents of an iframe's srcdoc content attribute. This mean that what I'm calling "nontraditional srcdoc documents" technically didn't have the same behavior required by any part of the spec that defined behavior specifically for "an iframe srcdoc document". Nontraditional srcdoc documents can be constructed by either document.open() or navigating to a javascript: URL inside of an about:srcdoc iframe.

This PR removes the distinction between nontraditional srcdoc documents and the classic "iframe srcdoc documents" by introducing the "matches about:srcdoc" concept for URLs, and defining "an iframe srcdoc document" as a thin alias over this concept. This proposal was described by #9514 (comment).

Additionally, this new concept ensures that about:srcdoc#foo documents (modified via history.replaceState(null, '', 'about:srcdoc#foo')) are also counted as normal srcdoc documents, although Chromium and Firefox currently have issues with this (see bugs below).

• At least two implementers are interested (and none opposed):
  • Safari
  • Chrome (mostly)
  • Gecko (mostly)
• Tests are written and can be reviewed and commented upon at:
  • Navigation: non-traditional about:srcdoc WPTs web-platform-tests/wpt#41066
• Implementation bugs are filed:
  • Chromium: https://bugs.chromium.org/p/chromium/issues/detail?id=1465972
  • Gecko: https://bugzilla.mozilla.org/show_bug.cgi?id=1844202
• MDN issue is filed: …

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

Closes #9514.

---

/iframe-embed-object.html ( diff )
/urls-and-fetching.html ( diff )

[domfarolino]

I'm not sure if the navigation label really belongs on this PR since we're mostly impacting the behavior of srcdoc documents once navigated to. Separately, there may be other places in the spec where about:srcdoc being used raw should be replaced with matches about:srcdoc now, but I think I'd like to roll that evaluation into #9488 and make that issue about evaluating the "matches" algorithms more completely.

[domenic]

At first I felt that it was a bit of a layering violation for something that operates at the URL level to know about the fact that, at the document/iframe/history API level, we'll never modify these to have a query.

But then I realize we do basically the same thing for "matches about:blank", with username and password and host. So probably it's fine.