Repository navigation
Top-level navigations to blob URLs with media mime types result in resource load subject to partitioning #210
Description
In #153 we decided to partition blob URLs except for top-level navigations. One edge case is that if the blob URL has a media mime type, a Document is created and the blob URL is eventually loaded via a "video" element (at least when I tried with a .wav file and a .mp4 file, and IIUC the spec for this behavior is here [1]). If the blob URL was created in a third-party context, the navigation to the blob URL will succeed but the resource load won't because the third-party blob URL is being loaded from a first-party context.
From some testing, Firefox already allows this resource load to complete successfully. I tried testing in Safari but .wav / .mp4 files didn't seem to be supported in general. It seems like allowing the resource load in this case is the right thing to do.
To change this from a spec perspective, we could somehow tag the resource load as being associated with the top-level navigation and thus exempt from partitioning, although we might have to pass that value through a lot of layers and it seems more difficult to implement this (at least in Chromium). Alternatively, we could allow unpartitioned blob URL resource loads by first-party contexts when the resource blob URL being loaded equals the URL of the document itself. It seems intuitive to me that a blob URL document should be able to fetch itself regardless of which context it was created in.
WDYT? +CC @mkruisselbrink @annevk @artines1
See also: https://crbug.com/426787402
[1] https://html.spec.whatwg.org/multipage/document-lifecycle.html#read-media
Activity
mkruisselbrink commentedon Jun 24, 2025
What would break if we somehow let top-level navigations to blob URLs inherit the partition key from the blob URL? I think that would mean that blob: URL documents could load any blob: URLs from the same origin and partition, solving at least this case. Not sure if it would be more or less problematic for other cases, or how hard that would be to implement in various browsers.
annevk commentedon Jun 24, 2025
If this only impacts top-level documents and those documents can't have an opener, it doesn't really matter what solution we pick I think, as long as it's constrained to those documents.
recvfrom commentedon Jun 24, 2025
Hmm, it's possible that sites could be relying on a newly opened window having a first-party storage key, although cross-top-level-site blob URL navigations aren't very common: https://chromestatus.com/metrics/feature/timeline/popularity/5200 For the Chromium implementation I wonder if there could be challenges with code assuming that an outer-most frame has a first-party storage key. @arichiv did you run into any of these issues when implementing support for partitioned popins?
For the Chromium implementation there is one case where this mitigation would also be helpful even when an opener is set, which is when a media blob URL is created from and navigated to by an A -> B -> A iframe. We wouldn't set noopener because it's not a cross-top-level site navigation, but the resource load after the navigation would still fail because the "is-cross-site" boolean associated with the blob URL being true would make it a cross-partition fetch. Maybe this case doesn't matter too much, though.
arichiv commentedon Jun 24, 2025
We didn't get far enough in popin developer testing to really notice blob related bugs I think.
annevk commentedon Jun 24, 2025
That does make the strategy theoretically observable, though I haven't figured out a way to make it actually observable. Thus far I like comparing the URL to the document URL coupled with it being a top-level document best.
recvfrom commentedon Nov 14, 2025
I have a preliminary PR for what this might look like in the fetch spec: whatwg/fetch#1879
Along with that change we would update "obtain a blob object" in the File API spec so that the second argument is
an [=environment settings object=], the string "navigation", or the string "top-level-self-fetch". It will bypass partitioning in the "navigation" and "top-level-self-fetch" case.Also, we'd update https://html.spec.whatwg.org/multipage/media.html#concept-media-load-resource to pass "top-level-self-fetch" to "obtain a blob object" similarly to how it's done in the fetch PR.
I'll work on creating PRs for those other but in the meantime if anyone thinks we should implement this a different way (for instance passing the required context into "obtain a blob object" so that it can determine when the "top-level-self-fetch" case is occurring) LMK
Add blob URL partitioning self-fetch test and refactor helper functions
Add blob URL partitioning self-fetch test and refactor helper functions
Add blob URL partitioning self-fetch test and refactor helper functions
annevk commentedon Nov 18, 2025
@domfarolino and @jakearchibald might have thoughts on the alternative routes, but I think what you have is fine as I think it's not observable.
domfarolino commentedon Nov 19, 2025
I don't see a problem with the current approach! Thanks for looping me in.
Bug 2000643 [wpt PR 56062] - Add blob URL partitioning self-fetch tes…
Bug 2000643 [wpt PR 56062] - Add blob URL partitioning self-fetch tes…
Bug 2000643 [wpt PR 56062] - Add blob URL partitioning self-fetch tes…
Bug 2000643 [wpt PR 56062] - Add blob URL partitioning self-fetch tes…
Bypass blob URL partitioning for top-level self fetches
Update "obtain a blob object" to handle top-level self-fetch
Update media resource fetch to identify top-level self-fetch for blob…
[Blob URL] Make top-level self-fetch WPT not tentative
[Blob URL] Make top-level self-fetch WPT not tentative
[Blob URL] Make top-level self-fetch WPT not tentative
Bug 2003941 [wpt PR 56468] - [Blob URL] Make top-level self-fetch WPT…
Update media resource fetch to identify top-level self-fetch for blob…
Update media resource fetch to identify top-level self-fetch for blob…