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

Status: RESOLVED FIXED

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

Description

[Boris Zbarsky [:bzbarsky]]

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?

Comment 1

[Jan de Mooij [:jandem]]

(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

Comment 2

[Jan de Mooij [:jandem]]

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.

Comment 3

[Boris Zbarsky [:bzbarsky]]

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.

Comment 4

[Boris Zbarsky [:bzbarsky]]

Attachment: Bug 1523843 part 1. Add a way to test whether a compartment is OK to share across Realms from SpiderMonkey's point of view. r=jandem

Comment 5

[Boris Zbarsky [:bzbarsky]]

Attachment: Bug 1523843 part 2. Use a single compartment for same-origin Realms in a single page (toplevel load). r=bholley

Comment 6

[Pulsebot]

Pushed by [e-mail]:
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

Comment 7

[Razvan Maries]

https://hg.mozilla.org/mozilla-central/rev/190cd12fb84e
https://hg.mozilla.org/mozilla-central/rev/1b528e3cac94

Comment 8

[Razvan Maries]

https://hg.mozilla.org/mozilla-central/rev/190cd12fb84e
https://hg.mozilla.org/mozilla-central/rev/1b528e3cac94

Comment 9

[Razvan Maries]

https://hg.mozilla.org/mozilla-central/rev/190cd12fb84e
https://hg.mozilla.org/mozilla-central/rev/1b528e3cac94