Update media resource fetch to identify top-level self-fetch for blob URLs

[recvfrom]

Updates the media resource fetch algorithm to calculate when a top-level self-fetch might be occurring for blob URLs, which is a case where blob URL partitioning would be bypassed.

For more info see: w3c/FileAPI#210

• At least two implementers are interested (and none opposed):
  • Implemented in Chromium: https://crbug.com/426787402
• Tests are written and can be reviewed and commented upon at:
  • I don't think this case is testable via WPTs... You'd need some way to navigate to a blob URL that has a media mime type and that was created in a third-party context (resulting in the creation of a first-party media document), and then be able to inspect the state of that document to see whether the video element played successfully. We enforce no-opener on cross-top-level-site blob URL navigations, so there's no handle to the new page, and we can't otherwise inspect it's state or execute code in it's context AFAIK. For testing Chrome's implementation we have a browser test that can run Javascript in the newly opened window
• Implementation bugs are filed:
  • Chromium: https://crbug.com/426787402
  • Gecko: https://bugzilla.mozilla.org/show_bug.cgi?id=2000324
  • WebKit: https://bugs.webkit.org/show_bug.cgi?id=302558
  • Deno (only for timers, structured clone, base64 utils, channel messaging, module resolution, web workers, and web storage): N/A since Deno does not partition storage or more generally implement the same-origin policy: https://docs.deno.com/runtime/reference/web_platform_apis/#spec-deviations
  • Node.js (only for timers, structured clone, base64 utils, channel messaging, and module resolution): N/A
• Corresponding HTML AAM & ARIA in HTML issues & PRs: N/A
• MDN issue is filed: TODO
• The top of this comment includes a clear commit message to use.

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

---

/media.html ( diff )

[annevk]

Suggested change

	<li><p>Let <var>stringOrEnvironment</var> be <var>settingsObject</var>.</p></li>
	<li><p>If <var>isTopLevelSelfFetch</var> is true, then set <var>stringOrEnvironment</var> to
	"<code data-x="">top-level-self-fetch</code>".</p></li>
	<li><p>Let <var>stringOrEnvironment</var> be "<code data-x="">top-level-self-fetch</code>" if
	<var>isTopLevelSelfFetch</var> is true; otherwise <var>settingsObject</var>.</p></li>

[annevk]

(There's a potentially gnarly edge case here with respect to using the element's relevant settings object or the element's node document's relevant settings object as they can currently be different if an element moves across documents, but I think we generally (maybe even exclusively) want to use the element's node document's relevant settings object.)