This will allow us to correctly handle CheckedUnwrapDynamic on wrappers around
WindowProxy and Location.
Differential Revision: https://phabricator.services.mozilla.com/D17882
--HG--
extra : moz-landing-system : lando
I am not a huge fan of the UnwrapReflectorToISupports setup here. Maybe we
should introduce two differently-named methods that make it somewhat clear what
the limitations of not taking a JSContext are? I couldn't think of sane
naming...
Differential Revision: https://phabricator.services.mozilla.com/D17885
--HG--
extra : moz-landing-system : lando
The basic idea for the changes around UnwrapObjectInternal and its callers
(UnwrapObject, UNWRAP_OBJECT, etc) is to add a parameter to the guts of the
object-unwrapping code in bindings which can be either a JSContext* or nullptr
(statically typed). Then we test which type it is and do either a
CheckedUnwrapDynamic or CheckedUnwrapStatic. Since the type is known at
compile time, there is no actual runtime check; the compiler just emits a call
to the right thing directly (verified by examining the assembly output on
Linux).
The rest of the changes are mostly propagating through that template parameter,
adding static asserts to make sure people don't accidentally pass nullptr while
trying to unwrap to a type that might be a WindowProxy or Location, etc.
There are also some changes to places that were calling CheckedUnwrap directly
to use either the static or dynamic version, as needed.
Differential Revision: https://phabricator.services.mozilla.com/D17883
--HG--
extra : moz-landing-system : lando
This will allow us to correctly handle CheckedUnwrapDynamic on wrappers around
WindowProxy and Location.
Differential Revision: https://phabricator.services.mozilla.com/D17882
--HG--
extra : moz-landing-system : lando
I am bit surprised myself, but just removing the getPropertyDescriptor trap seems to mostly work.
The only real special case here is the XPC Sandbox, which I changed to keep using its getPropertyDescriptorImpl.
testSetPropertyIgnoringNamedGetter.cpp didn't even really need its getPropertyDescriptor implementation.
Differential Revision: https://phabricator.services.mozilla.com/D17386
--HG--
extra : moz-landing-system : lando
This is needed to test the test harness's handling of a negative leak
being reported by the XPCOM leak checker.
Depends on D17535
Differential Revision: https://phabricator.services.mozilla.com/D17536
--HG--
extra : moz-landing-system : lando
In order to test the test harness's handling of a process failing to
produce a leak log, add a special function that disables the bloat log
output.
Differential Revision: https://phabricator.services.mozilla.com/D17534
--HG--
extra : moz-landing-system : lando
***
Bug 1514594: Part 3a - Change ChromeUtils.import to return an exports object; not pollute global. r=mccr8
This changes the behavior of ChromeUtils.import() to return an exports object,
rather than a module global, in all cases except when `null` is passed as a
second argument, and changes the default behavior not to pollute the global
scope with the module's exports. Thus, the following code written for the old
model:
ChromeUtils.import("resource://gre/modules/Services.jsm");
is approximately the same as the following, in the new model:
var {Services} = ChromeUtils.import("resource://gre/modules/Services.jsm");
Since the two behaviors are mutually incompatible, this patch will land with a
scripted rewrite to update all existing callers to use the new model rather
than the old.
***
Bug 1514594: Part 3b - Mass rewrite all JS code to use the new ChromeUtils.import API. rs=Gijs
This was done using the followng script:
https://bitbucket.org/kmaglione/m-c-rewrites/src/tip/processors/cu-import-exports.jsm
***
Bug 1514594: Part 3c - Update ESLint plugin for ChromeUtils.import API changes. r=Standard8
Differential Revision: https://phabricator.services.mozilla.com/D16747
***
Bug 1514594: Part 3d - Remove/fix hundreds of duplicate imports from sync tests. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16748
***
Bug 1514594: Part 3e - Remove no-op ChromeUtils.import() calls. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16749
***
Bug 1514594: Part 3f.1 - Cleanup various test corner cases after mass rewrite. r=Gijs
***
Bug 1514594: Part 3f.2 - Cleanup various non-test corner cases after mass rewrite. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16750
--HG--
extra : rebase_source : 359574ee3064c90f33bf36c2ebe3159a24cc8895
extra : histedit_source : b93c8f42808b1599f9122d7842d2c0b3e656a594%2C64a3a4e3359dc889e2ab2b49461bab9e27fc10a7
The change to test_bug440572.html is due to a behavior change. Specifically,
before this change, any IDL-declared property, even one not exposed
cross-origin, would prevent named frames with that name being visible
cross-origin. The new behavior is that cross-origin-exposed IDL properties
prevent corresponding frame names from being visible, but ones not exposed
cross-origin don't. This matches the spec and other browsers.
Same thing for the changes to test_bug860494.xul.
The wpt test changes are just adding test coverage for the thing the other
tests caught.
Differential Revision: https://phabricator.services.mozilla.com/D15428
--HG--
extra : moz-landing-system : lando
This patch removes the StopWatch code that was used in the first version of
about:performance, and not being used anymore.
Differential Revision: https://phabricator.services.mozilla.com/D7453
--HG--
extra : moz-landing-system : lando
This does the following:
- It introduces a controlling ifdef ENABLE_WASM_REFTYPES that enables
exactly those features that are in the reftypes proposal, excluding
those in the gc proposal. Any remaining features (namely, ref.eq,
(ref T) types, struct types) are still under ENABLE_WASM_GC control.
ENABLE_WASM_GC requires ENABLE_WASM_REFTYPES and this is checked.
- It introduces a new TestingFunctions predicate, wasmReftypesEnabled,
that distinguishes reftype-proposal support from gc-proposal
support. We keep wasmGcEnabled to test for gc-proposal support.
- It segregates test cases so that gc-proposal relevant tests are in
their own files, and tests relevant to the reftypes-proposal are now
guarded by wasmReftypesEnabled.
- It renames the predicate HasGcSupport() as HasReftypesSupport(),
since that is what the predicate tests for.
- It has a drive-by fix for the DEBUG-only function wasm::Classify()
to properly put ref.null and ref.is_null under ifdef control.
Reftypes will soon be enabled unconditionally in Nightly (once we can
trace pointers from Ion frames) while gc-types will remain conditional
until Ion supports all the new instructions for struct types. Therefore:
- The command line switch and about:config option are still called
--wasm-gc and j.o.wasm_gc, respectively, which is fine since they will
fairly soon control only gc-proposal features.
- Internal names still use "Gc" rather than "Reftypes", eg,
HasGcTypes, wasmGc_, and so on. This is most appropriate since it
reduces the scope of the patch and these names will pertain mainly
to the gc feature in the future.
--HG--
extra : rebase_source : 51cf3bfe67da594e89195472e4ce1ccfa36c146d
This also changes test_bug1516237.html to now assert we're same-compartment
instead of supporting both cases.
Differential Revision: https://phabricator.services.mozilla.com/D15819
--HG--
extra : moz-landing-system : lando
This case can come up with same-compartment realms. Keeping these CCWs
would confuse RemapWrapper because it'd be called with the CCW and target
in the same compartment.
Differential Revision: https://phabricator.services.mozilla.com/D15491
--HG--
extra : moz-landing-system : lando
Make the WindowProxyHolder hold a strong reference to a BrowsingContext, as in the future
we might not have a nsPIDOMWindowOuter (if the document is loaded in a different process).
Differential Revision: https://phabricator.services.mozilla.com/D12651
--HG--
extra : moz-landing-system : lando
Changes the test to test both freshCompartment: true and freshCompartment: false
sandbox options.
There's one sub test that fails with same-copartment realms, I commented that
and added a weaker test for the same-compartment case.
Differential Revision: https://phabricator.services.mozilla.com/D15289
--HG--
extra : moz-landing-system : lando
Summary: Really sorry for the size of the patch. It's mostly automatic
s/nsIDocument/Document/ but I had to fix up in a bunch of places manually to
add the right namespacing and such.
Overall it's not a very interesting patch I think.
nsDocument.cpp turns into Document.cpp, nsIDocument.h into Document.h and
nsIDocumentInlines.h into DocumentInlines.h.
I also changed a bunch of nsCOMPtr usage to RefPtr, but not all of it.
While fixing up some of the bits I also removed some unneeded OwnerDoc() null
checks and such, but I didn't do anything riskier than that.
This helper code is currently unused, and presents a pretty significant
footgun for any JS object which implements nsIPropertyBag itself.
When those objects are first queried to nsIWritablePropertyBag, they behave as
expected, returning the JS-implemented nsIPropertyBag methods. But when
they're first queried to nsIPropertyBag, they use the XPCWrappedNative stubs,
which don't behave as expected.
Differential Revision: https://phabricator.services.mozilla.com/D15235
--HG--
extra : rebase_source : 02942592dc8c4efcc1190610448a46593faa5703
With same-compartment chrome globals these would end up in the same compartment.
We need to prevent that because the debugger doesn't support it.
Differential Revision: https://phabricator.services.mozilla.com/D15093
--HG--
extra : moz-landing-system : lando
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
