Closed Bug 1598131 Opened 1 year ago Closed 1 year ago

Cross-Origin-Embedder-Policy isn't passed to content process BrowsingContext

Categories

(Core :: DOM: Navigation, defect, P2)

defect

Tracking

()

RESOLVED FIXED
mozilla77
Tracking Status
firefox77 --- fixed

People

(Reporter: perry, Assigned: edenchuang)

References

(Regressed 1 open bug)

Details

(Whiteboard: [fission-], [wptsync upstream])

Attachments

(1 file)

I'm trying to block loading Dedicated Workers when there's a COEP mismatch. When running the WPT window-simple-success.https.html it appears that window-simple-success.https.html's BrowsingContext doesn't have the COEP that's in the document's response ("require-corp"). I'm checking the value in this case using WorkerPrivate::GetWindow()->GetBrowsingContext()->GetEmbedderPolicy().

I do see the COEP header being put on a BrowsingContext in the parent process when the document is initially loading, but I think a new BrowsingContext is created for the document after the COEP header is processed (and the header value isn't transferred to the new BrowsingContext).

Is window-simple-success.https.html supposed to fail here, or how am I supposed to notice the problem?

Flags: needinfo?(perry)

I was testing it by first applying the patches at https://bugzilla.mozilla.org/show_bug.cgi?id=1575090, in which case the worker load here should successfully complete because the document and worker have the same Cross-Origin-Embedder-Policy value. (The problem is that the worker isn't loading successfully.)

When loading the worker, there'll be a call to ScriptResponseHeaderProcessor::ProcessCrossOriginEmbedderPolicyHeader (only exists with the patch stack) in the process where the worker and document lives that tries to match the worker script header's COEP value with its owner's BrowsingContext's COEP value.

I think more general thing is that I see nsHttpChannel::ProcessCrossOriginEmbedderPolicyHeader called when loading the document, and it does set the right COEP value on a BrowsingContext, but then when I examine the BrowsingContext of that document after loading has completed, the COEP value isn't there. FWIW, after the COEP was set using the nsHttpChannel method, I saw a new BrowsingContext being created at https://searchfox.org/mozilla-central/rev/3483fb259b4edbe4594cfcc3911db97d5441b67d/dom/base/nsFrameLoader.cpp#362.

Flags: needinfo?(perry)

Hi Andreas, were you able to take a look?

Flags: needinfo?(afarre)

So I wonder if we're doing a remoteness change here, and that we're not propagating synced fields as we should. I'll continue checking tomorrow, just have to resolve some compilation issues.

Priority: -- → P3

So I tried to understand what's going on by adding BrowsingContext::DidSetEmbedderPolicy to log out when it got set, but I didn't really understand what I was seeing. Maybe that's something that you could check to see if setting the policy happens on the browsing context you're expecting to get it set on. Because it migth happen, but only too late due to async issues?

Flags: needinfo?(afarre) → needinfo?(perry)
See Also: → 1610852

This is a COEP bug, not a Fission bug.

Whiteboard: [fission-]

I am taking this bug to support COEP on workers and related API.

Assignee: nobody → echuang
Flags: needinfo?(echuang)

(In reply to Perry Jiang [:perry] from comment #2)

I was testing it by first applying the patches at https://bugzilla.mozilla.org/show_bug.cgi?id=1575090, in which case the worker load here should successfully complete because the document and worker have the same Cross-Origin-Embedder-Policy value. (The problem is that the worker isn't loading successfully.)

When loading the worker, there'll be a call to ScriptResponseHeaderProcessor::ProcessCrossOriginEmbedderPolicyHeader (only exists with the patch stack) in the process where the worker and document lives that tries to match the worker script header's COEP value with its owner's BrowsingContext's COEP value.

I think more general thing is that I see nsHttpChannel::ProcessCrossOriginEmbedderPolicyHeader called when loading the document, and it does set the right COEP value on a BrowsingContext, but then when I examine the BrowsingContext of that document after loading has completed, the COEP value isn't there. FWIW, after the COEP was set using the nsHttpChannel method, I saw a new BrowsingContext being created at https://searchfox.org/mozilla-central/rev/3483fb259b4edbe4594cfcc3911db97d5441b67d/dom/base/nsFrameLoader.cpp#362.

The new browingContext is created for process switching caused by COOP mismatching.

When doing the process switching, the isCOOPSwitch computed in SessionStore.jsm and used to determine whether replacing the original browsingContext or not.

https://searchfox.org/mozilla-central/rev/7fba7adfcd695343236de0c12e8d384c9b7cd237/browser/components/sessionstore/SessionStore.jsm#3088
https://searchfox.org/mozilla-central/rev/7fba7adfcd695343236de0c12e8d384c9b7cd237/browser/components/sessionstore/SessionStore.jsm#3148
https://searchfox.org/mozilla-central/rev/7fba7adfcd695343236de0c12e8d384c9b7cd237/browser/components/sessionstore/SessionStore.jsm#2978

If isCOOPSwitch is true, the new browsingContext will be created. However, the COEP value is not propagated to the new one. So, checking COEP fails for the worker creation since it checks with its owner's(the new browsingContext) COEP value.

Flags: needinfo?(perry)
Flags: needinfo?(echuang)
Priority: P3 → P2

Hello Andrea

Could you help to review this patch or transfer it to the proper one? Thanks.

Flags: needinfo?(afarre)
Flags: needinfo?(afarre)
Pushed by ccoroiu@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/dc96b30210da
Propagate the browsingContext's COEP to the new created one in nsFrameLoader::Recreate r=farre
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/23057 for changes under testing/web-platform/tests
Whiteboard: [fission-] → [fission-], [wptsync upstream]
Upstream web-platform-tests status checks passed, PR will merge once commit reaches central.
Upstream PR merged by moz-wptsync-bot
Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla77
Regressions: 1634419
You need to log in before you can comment on or make changes to this bug.