[meta] Make all moz-extension: loads COOP loads, and place them in separate BrowsingContextGroups
Categories
(Core :: DOM: Navigation, defect, P2)
Tracking
()
People
(Reporter: kmag, Assigned: nika)
References
Details
(Keywords: meta, Whiteboard: [fission:m5c])
Attachments
(7 files)
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review |
There are probably a lot of reasons to force extension pages to use COOP, but the most pressing is that all privileged extension pages can directly access any other privileged pages from the same extension. The problem with this is that we also have an invariant that any two content pages which can directly access each other must be in the same BrowsingContextGroup, which in the case of extension pages, does not actually hold.
The only way to fix the problem is to force the BrowsingContext for any extension page that we create into the same BrowsingContextGroup as any other pages that it can access. And in the cases where the page isn't the first thing loaded into a FrameLoader, the only way to do that is to completely replace any existing BrowsingContext with a new one, in the appropriate group. This is essentially the same behavior required for COOP, just with the added complexity of also controlling the group of that BrowsingContext.
Updated•5 years ago
|
Comment 2•5 years ago
|
||
M5c
Morphing this bug into a meta bug because Nika has WIP patches for part of this bug. kmag will file new blocking bugs for the other parts.
Comment 3•5 years ago
|
||
Nika recommends unassigning kmag for now. We should fix this bug for M5 Dogfooding, but it's not the most urgent bug.
Reporter | ||
Updated•5 years ago
|
Comment 4•5 years ago
|
||
Nika says 99% of this is implemented.
Affects non-Fission, too.
Every extension should have its own BrowsingContextGroup.
Updated•5 years ago
|
Comment 5•5 years ago
|
||
kmag says this bug doesn’t need to block Fission M5 Dogfooding because this bug affects non-Fission users, too.
Comment 6•4 years ago
|
||
kmag said Nika is taking over this one.
Assignee | ||
Comment 7•4 years ago
|
||
Assignee | ||
Comment 8•4 years ago
|
||
The goal with this is to avoid having multiple booleans and other values
computed in arbitrary places and used around the method, and instead pre-compute
common shared information, and group each remoteType special-case together.
Hopefully, this should make it easier to extend the behaviour in
MaybeTriggerProcessSwitch in the future.
Assignee | ||
Comment 9•4 years ago
|
||
This is done by tracking a specific BrowsingContextGroup ID on the
WebExtensionPolicy in the parent process. Whenever a load is done with that
policy, the browsing context is replaced to ensure it is loaded in the correct
BrowsingContextGroup.
This patch also ensures that extension iframes are always loaded in the same
process as their embedder document, even if the frame was previously remote.
Assignee | ||
Comment 10•4 years ago
|
||
Assignee | ||
Comment 11•4 years ago
|
||
Comment 12•4 years ago
|
||
Comment 13•4 years ago
|
||
Backed out for twinopen failures
Backout link: https://hg.mozilla.org/integration/autoland/rev/b1146cce5053bf690a8b19f8da7ca97b1f37438d
Log link: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=307151935&repo=autoland&lineNumber=2308
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Comment 14•4 years ago
|
||
This is done by reloading framescripts and re-attaching message listeners when
process switch events are fired.
Updated•4 years ago
|
Comment 15•4 years ago
|
||
Comment 16•4 years ago
|
||
Comment 17•4 years ago
|
||
Backed outfor bc failures at test_chrome_ext_contentscript_data_uri.html.
Backout link: https://hg.mozilla.org/integration/autoland/rev/99571b1367d3474c2aef37d99e9408243f34585c
Failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=308057987&repo=autoland&lineNumber=112496
Assignee | ||
Comment 18•4 years ago
|
||
Assignee | ||
Updated•4 years ago
|
Comment 19•4 years ago
|
||
Comment 20•4 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/8ae775aac9f7
https://hg.mozilla.org/mozilla-central/rev/e6252187b0a8
https://hg.mozilla.org/mozilla-central/rev/871123e639a8
https://hg.mozilla.org/mozilla-central/rev/4c1d7b36f035
https://hg.mozilla.org/mozilla-central/rev/a89a0e4bb31e
https://hg.mozilla.org/mozilla-central/rev/f817fd7a0a6d
https://hg.mozilla.org/mozilla-central/rev/2e058695addc
Updated•4 years ago
|
Comment 21•4 years ago
|
||
can we do something like a webextensions permission to exempt an extension so it doesn't break the urlbar focus on custom NTPs
Description
•