Closed Bug 1523843 Opened 6 years ago Closed 6 years ago

Figure out where to hang the compartments we might want to share across globals on the web

Categories

(Core :: DOM: Core & HTML, enhancement, P2)

enhancement

Tracking

()

RESOLVED FIXED
mozilla67
Tracking Status
firefox67 --- fixed

People

(Reporter: bzbarsky, Assigned: bzbarsky)

References

Details

Attachments

(2 files)

To do multiple windows per compartment, we need a setup where when we create a new window's global (see SelectZone in nsGlobalWindowOuter.cpp) we reuse the compartment of some existing global. Where does this existing global come from?

Seems like we might want a map from origins to compartments (because we don't really want to keep globals alive) living in the tabgroup. Need to sort out the lifetime issues around compartments (e.g. can we detect when they go away so we can remove them from the map?).

Jan, any thoughts on this?

Flags: needinfo?(jdemooij)

(In reply to Boris Zbarsky [:bzbarsky, bz on IRC] from comment #0)

Jan, any thoughts on this?

One option is to add JS_IterateCompartmentsInZone (similar to JS_IterateCompartments) and then use that in SelectZone to look for a compartment with a CompartmentOriginInfo that's same-origin with aPrincipal. That's linear though... A map might be nice.

Need to sort out the lifetime issues around compartments (e.g. can we detect when they go away so we can remove them from the map?).

We have a compartment-destroyed callback, we use that to destroy the CompartmentPrivate here:

https://searchfox.org/mozilla-central/rev/c07aaf12f13037c1f5a343d31f8291549e57373f/js/xpconnect/src/XPCJSRuntime.cpp#696

Flags: needinfo?(jdemooij)

Also, RealmCreationOptions::setExistingCompartment wants a JSObject. If we have a JS::Compartment* our options are to either add an overload that has a JS::Compartment* argument or to use js::GetFirstGlobalInCompartment.

Right, so I guess we could stick to the current "one zone per tab" setup and look for an existing compartment within that zone. That means you'd get a new compartment if you window.open() a same-origin page, but same-origin subframes would share a compartment. This would be the safe change, with minimal effects on GC, since it doesn't change zone boundaries from what we have now. And then we could think about experimenting further in followups, with actual data and whatnot. Maybe that's the way to go for the moment...

If we hang things off the docgroup, that changes zone boundaries to include things you window.open() if they're same-origin with you. The benefit is that we'd have fewer wrappers and it's clearer how to go about looking for the compartment, off the docgroup; the drawback is bigger zones.

Priority: -- → P2
Depends on: 1527905
Pushed by bzbarsky@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/190cd12fb84e part 1. Add a way to test whether a compartment is OK to share across Realms from SpiderMonkey's point of view. r=jandem https://hg.mozilla.org/integration/autoland/rev/1b528e3cac94 part 2. Use a single compartment for same-origin Realms in a single page (toplevel load). r=bholley
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla67
Depends on: 1530146
Depends on: 1529203
Blocks: 1529203
No longer depends on: 1529203
No longer blocks: 1529203
Component: DOM → DOM: Core & HTML
Depends on: 1561887
Regressions: 1561887
No longer depends on: 1561887
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: