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

Status: RESOLVED FIXED

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

Description

[Perry Jiang [:perry] [no longer employee, use ni?]]

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).

Comment 1

[Andreas Farre [:farre]]

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

Comment 2

[Perry Jiang [:perry] [no longer employee, use ni?]]

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.

Comment 3

[Perry Jiang [:perry] [no longer employee, use ni?]]

Hi Andreas, were you able to take a look?

Comment 4

[Andreas Farre [:farre]]

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.

Comment 5

[Andreas Farre [:farre]]

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?

Comment 6

[Chris Peterson [:cpeterson]]

This is a COEP bug, not a Fission bug.

Comment 7

[Eden Chuang[:edenchuang]]

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

Comment 8

[Eden Chuang[:edenchuang]]

(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.

Comment 9

[Eden Chuang[:edenchuang]]

Attachment: Propagate the browsingContext's COEP to the new created one in nsFrameLoader::Recreate

Comment 10

[Eden Chuang[:edenchuang]]

Hello Andrea

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

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/dc96b30210da
Propagate the browsingContext's COEP to the new created one in nsFrameLoader::Recreate r=farre

Comment 12

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/23057 for changes under testing/web-platform/tests

Comment 13

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream web-platform-tests status checks passed, PR will merge once commit reaches central.

Comment 14

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot

Comment 15

[Dorel Luca [:dluca]]

https://hg.mozilla.org/mozilla-central/rev/dc96b30210da