JSStackFrames are C++ objects that are exposed to chrome JS and keep
alive content JS. This means that if chrome JS leaks a stack frame
then a window can be leaked.
The basic idea of this patch is to think of JSStackFrames as
cross-compartment wrappers, and do a "hueyfix" on them by dropping the
content JS reference when the associated content window is closed.
To do that, this patch modifies the realm private to keep a list of
all live JSStackFrames that have been created with objects in that
realm. When we nuke that realm, we also clear out all of the JS
pointers from the registered stack frames on that realm.
This adds a hash table lookup to the JSStackFrame ctor and dtor, which
is hopefully not too much overhead.
The test works by intentionally leaking a JSStackFrame from chrome JS
and making sure that the window still goes away.
Differential Revision: https://phabricator.services.mozilla.com/D14880
--HG--
extra : moz-landing-system : lando
JSStackFrames are C++ objects that are exposed to chrome JS and keep
alive content JS. This means that if chrome JS leaks a stack frame
then a window can be leaked.
The basic idea of this patch is to think of JSStackFrames as
cross-compartment wrappers, and do a "hueyfix" on them by dropping the
content JS reference when the associated content window is closed.
To do that, this patch modifies the realm private to keep a list of
all live JSStackFrames that have been created with objects in that
realm. When we nuke that realm, we also clear out all of the JS
pointers from the registered stack frames on that realm.
This adds a hash table lookup to the JSStackFrame ctor and dtor, which
is hopefully not too much overhead.
The test works by intentionally leaking a JSStackFrame from chrome JS
and making sure that the window still goes away.
Differential Revision: https://phabricator.services.mozilla.com/D14880
--HG--
extra : moz-landing-system : lando
For *incoming* wrappers this preserves behavior. We nuke *outgoing* wrappers
when all realms in the compartment have been nuked. To implement this I moved
the wasNuked flag from XPConnect to JS::Compartment as nukedOutgoingWrappers and
to JS::Realm as nukedIncomingWrappers.
The code to create a dead wrapper in the nuked compartment/realm case was also
moved into the JS engine. I added a shell test for it.
Differential Revision: https://phabricator.services.mozilla.com/D14149
--HG--
extra : moz-landing-system : lando
For *incoming* wrappers this preserves behavior. We nuke *outgoing* wrappers
when all realms in the compartment have been nuked. To implement this I moved
the wasNuked flag from XPConnect to JS::Compartment as nukedOutgoingWrappers and
to JS::Realm as nukedIncomingWrappers.
The code to create a dead wrapper in the nuked compartment/realm case was also
moved into the JS engine. I added a shell test for it.
Differential Revision: https://phabricator.services.mozilla.com/D14149
--HG--
extra : moz-landing-system : lando
Adding the Places* files into unified sources pushed the
unified sources into a situation that exposed a strangely
large number of errors. This seems to be the minimum set of
changes I could make to resolve all of the issues.
MozReview-Commit-ID: C2H9ce8FmE4
--HG--
extra : rebase_source : 61afc5481dc8ec34caba1886bd74200cf3659fb4
Adding the Places* files into unified sources pushed the
unified sources into a situation that exposed a strangely
large number of errors. This seems to be the minimum set of
changes I could make to resolve all of the issues.
MozReview-Commit-ID: C2H9ce8FmE4
--HG--
extra : rebase_source : 4f8dd2996d820fdb5a07afe544be5e2d6ca6a5c7
Adding the Places* files into unified sources pushed the
unified sources into a situation that exposed a strangely
large number of errors. This seems to be the minimum set of
changes I could make to resolve all of the issues.
MozReview-Commit-ID: C2H9ce8FmE4
--HG--
extra : rebase_source : b01f47e439a61492ad999ae30677c48535e8cd4c
Adding the Places* files into unified sources pushed the
unified sources into a situation that exposed a strangely
large number of errors. This seems to be the minimum set of
changes I could make to resolve all of the issues.
MozReview-Commit-ID: C2H9ce8FmE4
--HG--
extra : rebase_source : 571fd3b1e6511daa5731da76fb5d6d97bce11db1
Adding the Places* files into unified sources pushed the
unified sources into a situation that exposed a strangely
large number of errors. This seems to be the minimum set of
changes I could make to resolve all of the issues.
MozReview-Commit-ID: C2H9ce8FmE4
--HG--
extra : rebase_source : 7a3b71596b4318f517ec4c3ac0180e2aa3b721c7
* GetScriptCompartment => GetScriptRealm
* Adds IsSystemRealm in addition to IsSystemCompartment and uses it where we can.
* JS_GetCompartmentPrincipals and IsSystemCompartment now release-assert they have a single realm. This is temporary until we know what Gecko will do/need exactly.
Kris Maglione
arthur.iakab
Randell Jesup
Andrew McCreight
Andreea Pavel
Jan de Mooij
Ciure Andrei
Sylvestre Ledru
Doug Thayer
Dorel Luca
Bogdan Tara
Jason Orendorff
Nika Layzell