User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:126.0) Gecko/20100101 Firefox/126.0

Steps to reproduce:

1. Visit https://www.bitstamp.net/market/tradeview/

Actual results:

The TradeView component on the page does not load after the update to Firefox 126.0 on all of my devices.

Expected results:

The Tradeview component should have loaded like it did in previous versions and other browsers.

I can reproduce the issue on Nightly128.0a1 Windows11 and Ubuntu22.04.
Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=f90991ecf54d9ca0f1fa118ed2398418cd2f9092&tochange=e786976ead27e945bbd35ee4e80c8395af6405de

:bvandersloot could you please take a look?
Tracking since there is a known site impact.
Mentioning we have a dot release for Fx126 scheduled for next week.

Thinking aloud here: this is an iframe whose source is a blob URL created by the parent document. This has to do with part 1 of Bug 1876575. I'll work on this further.

This working with ETP disabled is an interesting wrinkle. I would not expect that from such a breakage. And the blob document is being correctly identified as first party with ETP disabled. So that appears to have been a red herring.

Looking at the console, there are syntax errors with ETP enabled that are not present with it disabled. This seems like a good thread to pull...

And it was the blob url doc! It was forcing all subresources in the blob iframe to be third-party. this was due to a bad choice in https://phabricator.services.mozilla.com/D205231. Blobs should be special cased in the AntiTrackingUtils code too.

trying https://treeherder.mozilla.org/jobs?repo=try&revision=beec40814b38d240f59ec5a246d109a4257cdfea

We debated over whether or not to do this in https://phabricator.services.mozilla.com/D205231.
It turns out we should have.

If we don't do this, the blob document thinks it is third party, so its subresources become foreign
and don't have access to the first party cookies. All because blob urls don't have a host, so they don't
have a base domain.

The bug is marked as tracked for firefox126 (release), tracked for firefox127 (beta) and tracked for firefox128 (nightly). However, the bug still has low severity.

:dmehic, could you please increase the severity for this tracked bug? If you disagree with the tracking decision, please talk with the release managers.

For more information, please visit BugBot documentation.

This came up in the triage meeting yesterday and we opted for S3. One could argue that because of impact this is an S2.

We talked about this again, bumping to S2.

:bvandersloot adding a reminder the Fx126 dot release is scheduled for next week.
The deadline for uplifts is eod tomorrow (Friday 2024-05-24)
The patch hasn't landed yet and might be too risky to include in a dot release.
What are your thoughts on risk? We should aim to include this in Beta for Fx127 at least.

There is some risk involved here for a release uplift since the patch is non-trivial. I'll aim for beta. I'm willing to hear arguments for release if anyone involved is passionate.

(In reply to Benjamin VanderSloot [:bvandersloot] from comment #12)

There is some risk involved here for a release uplift since the patch is non-trivial. I'll aim for beta. I'm willing to hear arguments for release if anyone involved is passionate.

:bvandersloot we are in the final week of beta for Fx127. There are only two beta builds left, the last Fx127 beta builds on 2024-05-31.
There's limited time for this to land in central and then get a beta uplift request.

We debated over whether or not to do this in https://phabricator.services.mozilla.com/D205231.
It turns out we should have.

If we don't do this, the blob document thinks it is third party, so its subresources become foreign
and don't have access to the first party cookies. All because blob urls don't have a host, so they did't
have a base domain. But they do have origins, which is what base domain should be derived from.

Backed out for causing wpt failures in url-reload.window.html.

• Backout link
• Push with failures
• Failure Log
• Failure line: TEST-UNEXPECTED-TIMEOUT | /FileAPI/url/url-reload.window.html | Reloading a blob URL succeeds. - Test timed out

So, good news and bad news. The good news is that the patch above fixes the bug identified. The bad news is that it causes a timeout on blob reload because of a bug in the repartitioning work, related to the recent Bug 1736488. In particular, some first-level-frame navigations seem to be treating their parent as third party, forcing the foreign bit on the partition key. I'm going to diagnose that and fix it.

:asuth, if it comes down to it, which do you prefer?

1. a late Beta uplift for this, marking the WPT as failing
2. leave this bug in 127, and uplift this and the fix for repartitioning into 128 once I finish it?

Scratch that- false alarm on the reasoning. This had to do with an actual bug in the patch that made our revoked handling logic not work.

Lesson: IsBlobURL means "is active blob url". I wanted to check the scheme.

It would definitely be great to improve the method name there (in a different patch and likely bug), as indeed that method name seems to be a foot-gun!

Also, if it helps, I asked pernosco to get a reproduction because at first glance I thought the problem was that nsDocShell::Reload might be re-parsing the URL when it should not, although the timing seemed suspect:
https://pernos.co/debug/N5VmgODybbprTC-f0d_3RQ/index.html

(Noting that there's still potentially the issue of whether we would actually pass the test after our revocation timer fires. Ideally the docshell would be retaining a reference to the Blob under the hood, but I'm not sure that it is.)

https://hg.mozilla.org/mozilla-central/rev/2b327975c109

The patch landed in nightly and beta is affected.
:bvandersloot, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox127 to wontfix.

For more information, please visit BugBot documentation.

Given the late status of beta and risk of the patch, let's not uplift.

The website mentioned in the reproduction steps has worked around the problem and cannot be used anymore.

Based on comment #26 not sure how to verify the fix since it is not reproducing anymore.
Limeclipse, if you still reproduce the issue on latest Firefox 128 (https://archive.mozilla.org/pub/firefox/candidates/128.0b5-candidates/), please add a comment here. Thank you.