Closed Bug 1482835 Opened Last year Closed Last year
_Get Compartment Principals calls in the compartment nuking code
46 bytes, text/x-phabricator-request
|Details | Review|
The main one, in BrowserCompartmentMatcher, checks IsSystemOrExpandedPrincipal. Looking at the history of this code, this used to check for just system compartments. Bug 1174950 then changed that to include expanded principals to deal with add-on sandboxes keeping globals alive (the idea is that web content doesn't use expanded principals). One option is to add xpc::IsMaybeWebContentCompartment that returns false if js::IsSystemCompartment(compartment) is true and else checks a flag on the CompartmentPrivate (we can set this when we create a sandbox with expanded principals).
This implements what's described in comment 0. However there might be a better way to do this if we decide to store principal-related info in JS::Compartment so I'm holding off on this for now.
Comment on attachment 8999556 [details] [diff] [review] Remove JS_GetCompartmentPrincipals calls from compartment nuking code We can now use the origin principal stored in CompartmentPrivate.
Attachment #8999556 - Attachment is obsolete: true
Comment on attachment 9009088 [details] Bug 1482835 - Remove JS_GetCompartmentPrincipals calls in the compartment nuking code. r?mccr8 Andrew McCreight [:mccr8] has approved the revision.
Attachment #9009088 - Flags: review+
Pushed by email@example.com: https://hg.mozilla.org/integration/autoland/rev/e0802d8df93a Remove JS_GetCompartmentPrincipals calls in the compartment nuking code. r=mccr8
You need to log in before you can comment on or make changes to this bug.