The code was trying to implement the getOwnPropertyDescriptor trap in terms of
getPropertyDescriptor, by comparing the "holder" object we found to the object
we did the lookup on. This becomes buggy when wrappers like WindowProxy are involved.
The patch removes this check and calls JS_GetOwnPropertyDescriptor instead of
JS_GetPropertyDescriptor.
Differential Revision: https://phabricator.services.mozilla.com/D15091
--HG--
extra : moz-landing-system : lando
Reasons for doing this:
* nsXPCWrappedJS has complicated GC behavior and we're seeing some oranges in this area.
* Due to the GC/CC complexity, the global stored in nsXPCWrappedJS *must be* the
object's global in the root-wrapper (implies non-CCW) case. If we do that, the
global is redundant because we can just get it from the object when we need it.
* For the CCW case, it probably doesn't matter too much which chrome global we
use so we can use the compartment's first global - we now have an API for that.
This may also save some memory because it avoids keeping globals alive unnecessarily
and matches what we do for WrappedNatives and CCWs now. Furthermore, bug 1478359
comment 12 suggests CCWs can only show up here for in-content XBL and that's in the
process of being removed.
Differential Revision: https://phabricator.services.mozilla.com/D15096
--HG--
extra : moz-landing-system : lando
This needs to be on the compartment to prevent creating duplicate wrapped natives.
We now also allocate these objects in the compartment's first global for
consistency and to prevent leaks.
XPCWrappedNativeScope also stores the content XBL scope. I considered moving
this to RealmPrivate, but given the fate of in-content XBL I went with the
simpler option of keeping it on XPCWrappedNativeScope and release-asserting we
have a single realm in the XBL case.
Because XPCWrappedNativeScope no longer stores a global object, we no longer
need XPCWrappedNativeScope::TraceSelf, XPCWrappedNativeProto::TraceInside and
XPC_WN_Proto_Trace.
Differential Revision: https://phabricator.services.mozilla.com/D14849
--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
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
The pref dom.chrome_frame_access.enabled will default to true. When false, it will block various methods that chrome code can use to traverse subframes. The initial list is:
iframe.contentWindow
iframe.contentDocument
window.top
window.parent
window.opener
window.frames[i]
window.frames.length
MessageEvent.source
More blocks are likely to be added in the future.
Differential Revision: https://phabricator.services.mozilla.com/D13180
--HG--
extra : moz-landing-system : lando
This helper makes it considerably easier for C++ code to import a JS module
and wrap it in an appropriately-defined XPIDL interface for its exports.
Typical usage is something like:
Foo.jsm:
var EXPORTED_SYMBOLS = ["foo"];
function foo(bar) {
return bar.toString();
}
mozIFoo.idl:
interface mozIFoo : nsISupports {
AString foo(double meh);
}
Thing.cpp:
nsCOMPtr<mozIFoo> foo = do_ImportModule(
"resource://meh/Foo.jsm");
MOZ_TRY(foo->Foo(42));
Differential Revision: https://phabricator.services.mozilla.com/D14209
--HG--
extra : rebase_source : 4d518205b173fc210908235b42ddace590e6b7e5
Because it release-asserts the compartment has a single realm.
I also renamed JS_GetCompartmentPrincipals to JS_DeprecatedGetCompartmentPrincipals
to discourage people from using it.
Differential Revision: https://phabricator.services.mozilla.com/D14252
--HG--
extra : moz-landing-system : lando
Replace with just unwrapping the key, since there are no users that return anything else for a delegate.
--HG--
extra : rebase_source : e72b825121ca3493364c9347f65e5dddd1ef53e0
We have a few places where C++ calls ChromeUtils::Import directly.
I fixed these to pass the target object directly instead of an empty Optional<>.
Differential Revision: https://phabricator.services.mozilla.com/D14180
--HG--
extra : moz-landing-system : lando
With same-compartment-realms enabled we can call a cross-realm Cu.importGlobalProperties
and we ended up defining properties on the wrong global.
Differential Revision: https://phabricator.services.mozilla.com/D14179
--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
Ensure that "a instanceof b" has Xray semantics, i.e. that when b is a
XrayWrapper, that the wrapped object's getters, `Symbol.hasInstance`
hook and proxy traps are not triggered.
The toolkit/components/mozintl/test/test_mozintlhelper.js test was
updated to explicitly waive Xrays, instead of relying on the previous
behavior where Xrays were automatically waived.
Depends on D11591
Depends on D11591
Differential Revision: https://phabricator.services.mozilla.com/D11592
--HG--
extra : moz-landing-system : lando
- modify line wrap up to 80 chars; (tw=80)
- modify size of tab to 2 chars everywhere; (sts=2, sw=2)
--HG--
extra : rebase_source : 7eedce0311b340c9a5a1265dc42d3121cc0f32a0
extra : amend_source : 9cb4ffdd5005f5c4c14172390dd00b04b2066cd7
This is a best effort attempt at ensuring that the adverse impact of
reformatting the entire tree over the comments would be minimal. I've used a
combination of strategies including disabling of formatting, some manual
formatting and some changes to formatting to work around some clang-format
limitations.
Differential Revision: https://phabricator.services.mozilla.com/D13193
--HG--
extra : moz-landing-system : lando
These macros tend to be handled quite poorly since the clang-format
tokenizer cannot figure out how to handle them.
Differential Revision: https://phabricator.services.mozilla.com/D13179
--HG--
extra : moz-landing-system : lando
It was removed in bug 1478275, but re-introduced because of a false rebase in bug 1431255.
Differential Revision: https://phabricator.services.mozilla.com/D12331
--HG--
extra : moz-landing-system : lando
This is a complete rewrite of the interface while maintaining the same APIs.
Each ID is fully-contained within a single object, does not require a finalizer,
and is cheap to create.
Beyond using reserved slots, this code avoids using custom ClassOps, instead
preferring Symbol.hasInstance and eager constants.
One major change which occurred in this patch was the move from storing a nsCID
to storing the ContractID for JSCID objects. This eliminates the need for the
'refreshCID' method, and hopefully shouldn't have performance implications.
If we discover that there are performance problems there, we can look into
stashing the CID, and re-introduce 'refreshCID', despite its surprising
behaviour.
Differential Revision: https://phabricator.services.mozilla.com/D2286
These two interfaces are effectively never used, so to avoid needing to support
ClassID2JSValue with the new implementation, I remove them entirely.
Differential Revision: https://phabricator.services.mozilla.com/D2285
This mostly consists of changes to the XPCComponents objects to avoid using the
implementation details, and instead use the API defined in part 1.
Differential Revision: https://phabricator.services.mozilla.com/D2284
This lets us get rid of the method 'initalize', which currently needs the
internal representation of JSCID.
This particular method is removed entirely in Part 9, and only exists to keep
intermediate states building & running.
Differential Revision: https://phabricator.services.mozilla.com/D2282
This should be mostly compatible with the original implementation. I tried to
simplify things here to just directly wrap and use JS objects, calling methods
on them. This eliminates the nsXPCConstructor type completely, replacing it with
a JSNative constructor with predefined READONLY | PERMANENT properties.
Differential Revision: https://phabricator.services.mozilla.com/D2280
This is the first part of hiding the implementation of nsIJSID behind the
interface added in Part 1, such that we can substitute that implementation out.
I had to make a couple of changes to fix the errors caused by the new behaviour
in GenerateQI.
Differential Revision: https://phabricator.services.mozilla.com/D2279
The new API tries to be more generic, taking and producing JS::Values. It also
supports creating the more specialized IID and CID types.
Differential Revision: https://phabricator.services.mozilla.com/D2278
This patch introduces 2 new prefs:
- devtools.console.stdout.chrome: if true, console API writes on stdout when
used by chrome code
- devtools.console.stdout.content: console API write on stdout when used by
content code.
Previously disabled via bug 1433905 to allow a refactoring of Marionette, this test can be re-enabled now given that bug 1433873 also got landed.
Differential Revision: https://phabricator.services.mozilla.com/D11744
--HG--
extra : moz-landing-system : lando
This was only ever useful before we had compartment-based security isolation.
Now it is just a pervasive nuisance.
Differential Revision: https://phabricator.services.mozilla.com/D10795
--HG--
extra : rebase_source : 9af37bbd959b2db3d7a6c5ac723a474c47676f79
These tests were timing out because `about:home` now runs in a different process.
Since these two tests aim to test something else (e.g. window leaks when
navigating between pages), we will redirect to a URL that loads in the same
process instead of `about:home` to avoid adding extra conditions for the
process flip.
See Bug 1336811 and Bug 1242643.
MozReview-Commit-ID: G0rhfA973R9
--HG--
extra : source : a28443371b944ee00b1267dd5b9a22da6d28353b
extra : intermediate-source : 7b7fa6ab2229e358666d0b0855adcfe6bd8199c4
extra : histedit_source : 6dae3cdd2834fc39ba547520cc6016ce4496cc08
These tests were timing out because `about:home` now runs in a different process.
Since these two tests aim to test something else (e.g. window leaks when
navigating between pages), we will redirect to a URL that loads in the same
process instead of `about:home` to avoid adding extra conditions for the
process flip.
See Bug 1336811 and Bug 1242643.
MozReview-Commit-ID: G0rhfA973R9
--HG--
extra : rebase_source : 158eb53174faa028edeebaf5970c123ba359a3e5
extra : intermediate-source : ebdca743668ce014c1cb9adfa00c1220256d357c
extra : source : a28443371b944ee00b1267dd5b9a22da6d28353b
These tests were timing out because `about:home` now runs in a different process.
Since these two tests aim to test something else (e.g. window leaks when
navigating between pages), we will redirect to a URL that loads in the same
process instead of `about:home` to avoid adding extra conditions for the
process flip.
See Bug 1336811 and Bug 1242643.
MozReview-Commit-ID: G0rhfA973R9
--HG--
extra : rebase_source : 614b8f5ac2a3ae9a1027c989d37aeba1026f886a
extra : source : a28443371b944ee00b1267dd5b9a22da6d28353b
I left GetMethodInfo, GetConstant as they are still useful as separate methods.
Differential Revision: https://phabricator.services.mozilla.com/D9638
--HG--
extra : moz-landing-system : lando
After the previous patches, we no longer rely on the component manager
to incidentally start up XPConnect when we load the JS loader service
or to hold the JS component loader alive, so the do_GetService() call
for the JS loader in XPCOMInit.cpp can be removed. After that is done,
the JS loader is no longer used as an XPCOM component, so all of the
boilerplate for that can be removed.
Depends on D8757
Differential Revision: https://phabricator.services.mozilla.com/D8758
--HG--
extra : moz-landing-system : lando
The JS component loader is an XPCOM component, so it is held alive by
the component manager. In order to be able to make it no longer be an
XPCOM component, we have to keep it alive some other way. I decided to
simply keep it alive as long as XPConnect itself is alive.
Depends on D9583
Differential Revision: https://phabricator.services.mozilla.com/D8757
--HG--
extra : moz-landing-system : lando
This changeset updates all the test that were wrongly using ok() and wanted to
use is() AND for which the assert is still passing without any modification
required.
Differential Revision: https://phabricator.services.mozilla.com/D8739
--HG--
extra : moz-landing-system : lando
Now that the XPCOM component loader infrastructure has stopped
pretending to support other file extensions, this intermediate
interface is no longer needed.
Depends on D8171
Differential Revision: https://phabricator.services.mozilla.com/D8172
--HG--
extra : moz-landing-system : lando
JS is the only file extension actually supported, and there are a few
layers of cruft that can be eliminated if we specialize it.
This eliminates one XPCOM registration of the JS component loader.
Depends on D8170
Differential Revision: https://phabricator.services.mozilla.com/D8171
--HG--
extra : moz-landing-system : lando
This interface is only used for a few testing functions. Just move
them to Cu.
Differential Revision: https://phabricator.services.mozilla.com/D8168
--HG--
extra : moz-landing-system : lando
SxS assemblies do not obey the usual DLL search order. It will make it possible
to load mozglue.dll from appdir even if the PreferSystem32Images mitigation is
enabled and System32 has a random mozglue.dll.
In FxAccountsComponents.manifest, the previous line registers the
component CID, but only for the main process. This means we hit an
error while parsing the manifest in the child process, because the CID
is not recognized. The fix is simply to not try to use the CID to
register the contract in the child process.
As for the rest of the changes, since bug 1438688, XPT information is
compiled into the Firefox binary, so the interfaces manifest entry is
no longer needed. This patch removes instances of this line from
manifest files. This makes some manifest files empty, so the patch
also removes the now-empty files.
Differential Revision: https://phabricator.services.mozilla.com/D8751
--HG--
extra : moz-landing-system : lando
This only requires changing the surrounding test boilerplate and using
SpecialPowers to access chrome-privileged functions.
Depends on D8132
Differential Revision: https://phabricator.services.mozilla.com/D8133
--HG--
extra : moz-landing-system : lando
This patch moves some Chrome mochitests into the plain mochitest
directory, in order to try to preserve the history. It also removes
them from the list of tests. The next patch will fix the tests and
start running them again.
Depends on D8131
Differential Revision: https://phabricator.services.mozilla.com/D8132
--HG--
rename : js/xpconnect/tests/chrome/test_getweakmapkeys.xul => js/xpconnect/tests/mochitest/test_getweakmapkeys.html
rename : js/xpconnect/tests/chrome/test_paris_weakmap_keys.xul => js/xpconnect/tests/mochitest/test_paris_weakmap_keys.html
rename : js/xpconnect/tests/chrome/test_weakmaps.xul => js/xpconnect/tests/mochitest/test_weakmaps.html
extra : moz-landing-system : lando
getter_AddRefs for nsCOMPtr does an AssertNoQueryNeeded check when its
temporary is destroyed. For the mReaderThread, this happens at a time when
control of the member variable has been handed over to the reader thread,
which causes a data race in the query needed check when the reader thread
shuts itself down and clears the member.
Switching to RefPtr solves this problem by removing the unnecessary check.
Differential Revision: https://phabricator.services.mozilla.com/D8135
--HG--
extra : rebase_source : 0532d152b6be57451e5729bf6b72e2056f3ed300
JIT warmup options were exposed to preferences to facilitate experimentation/optimization.
The baseline and ion warm up thresholds had already been exposed through JSAPI, just needed to read from Preferences.
The ion JitOption, frequentBailoutThreshold, was also exposed to JSAPI and Preferences.
Differential Revision: https://phabricator.services.mozilla.com/D7321
--HG--
extra : moz-landing-system : lando
Marionette currently doesn't handle restarts of Firefox that well,
and as such needs a fix on bug 1433873. Sadly this patch cannot be
landed until the mozprocess issues on bug 1433905 have been fixed.
This patch temporarily disables the test for opt/pgo Windows builds
only. Re-enabling is tracked via bug 1495667.
Differential Revision: https://phabricator.services.mozilla.com/D7392
--HG--
extra : moz-landing-system : lando
This method does very little, and is called in only a few places, so
just inline it. The error variant is not called at all. Simplifying
this makes it easier for me to change do_QueryInterface.
Differential Revision: https://phabricator.services.mozilla.com/D7527
--HG--
extra : moz-landing-system : lando
Move the implementation of the XBL tooltip to C++ so the element can safely
be created during native anonymous content creation. The 'mouseover' and
'mouseout' event handlers were not moved as they appear to be legacy code
that is no longer needed.
A number of tests started perma-failing after this patch. Most failures
were caused by a timing change where plugins sometimes load after the
document "load" event. Many of the failures had intermittents associated
with them and the tests were not waiting for plugins to load before
starting. The test "test_weakmap_keys_preserved2.xul" had a bug where it
was possible for it to finish before all the tests were run.
Differential Revision: https://phabricator.services.mozilla.com/D5065
--HG--
extra : moz-landing-system : lando
Some global imports, like `fetch`, expose multiple symbols. This patch
ensures we can define lazy getters for those symbols, by mapping the
extra symbol name to the main import name.
Differential Revision: https://phabricator.services.mozilla.com/D7522
--HG--
extra : moz-landing-system : lando
Calls to do_QueryInterface to a base class can be replaced by a static
cast, which is faster.
Differential Revision: https://phabricator.services.mozilla.com/D7224
--HG--
extra : moz-landing-system : lando
I can be more granular if we want, by adding more ChromeOnly annotations for the
functions that we don't want to expose.
Differential Revision: https://phabricator.services.mozilla.com/D6530
--HG--
extra : moz-landing-system : lando
A C++ object that is exposed to JS can have its reflector used as a
key in a weak map. Because a weak map does not keep its keys alive,
this means that the reflector can be discarded if it has no other
references aside from the C++ object, which will in turn remove its
weak map entry. If the C++ object can be accessed again later from JS,
it will get a new reflector which will have no weak map entry. This is
bad because it means some internal implementation detail has resulted
in data loss that is visible to JS. (Side note: this is also an issue
for cross compartment wrappers, which is handled by another
mechanism.)
To fix this, we can preserve the wrapper of any DOM reflector used as
a weak map key. This ensures that the reflector and its C++ object
have the same lifetime. If a WebIDL object is not wrapper cached, that
means that it cannot be accessed via C++, so we don't need to preserve
the wrapper. This is currently implemented for nsISupports classes,
but not other classes. For non-nsISupports classes, it would throw an
error rather than silently fail.
My patch adds support for non-nsISupports cycle collected objects. It
turns out that the existing addProperty hook just does wrapper
preservation, so we just call it for cycle collected classes. This
does mean that if addProperty changes in the future to do something
else, this code will need to be changed.
I verified that this test fails if TryPreserveWrapper is changed to do
nothing besides return true in the non-nsISuports case.
Depends on D6197
Differential Revision: https://phabricator.services.mozilla.com/D6198
--HG--
extra : moz-landing-system : lando
The patch in the next part will need a handle to the object in
TryPreserveWrapper.
Differential Revision: https://phabricator.services.mozilla.com/D6197
--HG--
extra : moz-landing-system : lando
We want to get rid of JS_GetCompartmentPrincipals. The origin stored in CompartmentPrivate does not account for document.domain changes because that's a per-realm thing.
Fortunately we should not have waivers in any cases that involve document.domain.
Differential Revision: https://phabricator.services.mozilla.com/D6035
--HG--
extra : moz-landing-system : lando
Also, make nsIXPCWrappedJSObjectGetter not scriptable to save a tiny amount of binary size.
Differential Revision: https://phabricator.services.mozilla.com/D5613
--HG--
extra : moz-landing-system : lando
This will let us answer the following questions (in a performant way):
1) What's the compartment's origin? Necessary to implement compartment-per-origin.
2) What's the origin's site? Necessary for the new Wrap() algorithm.
3) Has any realm in the compartment set document.domain? Necessary for the new Wrap() algorithm.
Differential Revision: https://phabricator.services.mozilla.com/D5423
--HG--
extra : moz-landing-system : lando
This allows JS callers and C++ callers to both create and consumer iterators
in their preferred style, while still presenting the appropriate interfaces to
callers in the other language.
When a C++ caller requires an nsISimpleEnumerator from an XPCWrappedJS object,
if that class does not already have a QueryInterface method, it is assumed to
be a JS enumerator, and an appropriate wrapper is created. JS callers who wish
to implement nsISimpleEnumerator manually, or opt out of the automatic
conversions, may implement a QueryInterface method, which automatically opts
them out of this behavior.
Differential Revision: https://phabricator.services.mozilla.com/D4290
--HG--
extra : rebase_source : eb61ee725a8c67e3e7f5b22d9aef9baa0cde1955
When an XPC wrapped JS object returns an object from a property or function
which is expected to return a given interface, we create a wrapper for that
interface regardless of whether the object has a QueryInterface method which
claims to support it. For the nsISimpleEnumerator enumerator case, the check
for that existing wrapper comes before the check for the nsISimpleEnumerator
special casing, which breaks automatic conversion in those cases.
This patch moves that check just before the check for the existing wrapper,
and just after the nsIPropertyBag special casing, which has similar semantics.
Differential Revision: https://phabricator.services.mozilla.com/D5335
--HG--
extra : rebase_source : 2201063455a2434cfa0c3c470f668fefa8528f4b
We move the XPConnect() singleton accessor to nsIXConnect to make it available for consumers outside of XPConnect. Most of the consumers of the singleton accessor just need the nsIXPConnect public interface, except for the IsShuttingDown() member which this patch adds to nsIXPConnect as well.
Differential Revision: https://phabricator.services.mozilla.com/D5151
We move the XPConnect() singleton accessor to nsIXConnect to make it available for consumers outside of XPConnect. Most of the consumers of the singleton accessor just need the nsIXPConnect public interface, except for the IsShuttingDown() member which this patch adds to nsIXPConnect as well.
Differential Revision: https://phabricator.services.mozilla.com/D5151
Jan de Mooij
Margareta Eliza Balazs
Luke Wagner
Razvan Maries
Jeff Walden
Andrew McCreight
Andreea Pavel
Bogdan Tara
Felipe Gomes
shindli
Kris Maglione
Boris Zbarsky
Steve Fink
Yoshi Cheng-Hao Huang
Jon Coppeard
Cameron Kaiser
André Bargull
Ciure Andrei
Rob Wu
Tooru Fujisawa
Benjamin Bouvier
Sylvestre Ledru
Coroiu Cristina
Ehsan Akhgari
Gabriele Svelto
Timothy Guan-tin Chien
Nika Layzell
Andrea Marchesini
Henrik Skupin
Andy Wingo
Dan Horák
Gurzau Raul
Kyle Machulis
Narcis Beleuzu
vinoth
Jonathan Kingston
Daniel Varga
Julian Descottes
Csoregi Natalia
Brindusan Cristian
Jay Lim
Sebastian Hengst
Adrian Wielgosik
Masatoshi Kimura
Dorel Luca
Brian Hackett
Andrew Creskey
Brendan Dahl
Lina Cambridge
Nicholas Nethercote
Eric Rahm
Emilio Cobos Álvarez
Jason Orendorff
Bobby Holley
Xidorn Quan
Dana Keeler
Mike Hommey