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
Makes the following changes:
* The WindowProxy optimizations in the ICs and Ion now guard the WindowProxy's
global is the script's global. Other WindowProxies are harder to optimize
because of potential security checks based on document.domain.
* IsWindowProxyForScriptGlobal was added as helper function to consolidate the
logic for this.
* Removes the WindowProxy optimization for CCWs. This becomes more complicated
in the new world for various reasons and it seems better to focus on
getting same-compartment realms working to address that use case.
Differential Revision: https://phabricator.services.mozilla.com/D15492
--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
This patch disables the following tests for the specified arm platform:
jit-test/tests/wasm/atomic.js arm64
jit-test/tests/wasm/baseline-abs-addr-opt.js arm64
jit-test/tests/wasm/bce.js arm64
jit-test/tests/wasm/memory.js arm64
jit-test/tests/wasm/spec/float_memory.wast.js arm7
jit-test/tests/wasm/spec/memory_redundancy.wast.js arm7
This uses the following rules to determine when to skip the
test:
skip arm7 // |jit-test| skip-if: !getBuildConfiguration()['x86'] && !getBuildConfiguration()['x64'] && !getBuildConfiguration()['arm64']
skip arm64 // |jit-test| skip-if: getBuildConfiguration()['arm64']
skip arm7+arm64 // |jit-test| skip-if: !getBuildConfiguration()['x86'] && !getBuildConfiguration()['x64']
Bug 1516915 has been filed to add an arm7 property to getBuildConfiguration.
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
This is the one thing preventing use of a js::Wrapper for a proxy handler that
forwards all ops to a wrapped proxy without entering its compartment. None of
the other ops at this level do compartment asserts.
Callers of this function other than ForwardingProxyHandler do their own asserts
already.
This add a simple function made to be called from gdb, which uses the vixl
decoder to output in a static buffer the string corresponding to a single
instruction.
This is useful when breaking at vixl::Simulator::ExecuteInstruction function, as follow:
(gdb) b vixl::Simulator::ExecuteInstruction
Breakpoint 1 at 0x...: file ../jit/arm64/vixl/MozSimulator-vixl.cpp.
(gdb) command 1
> call vixl::GdbDisassembleInstruction(this->pc_)
> end
As discussed on IRC this is hard to trigger, but this is more consistent with
the cross-compartment code.
Differential Revision: https://phabricator.services.mozilla.com/D15214
--HG--
extra : moz-landing-system : lando
This is consistent with what we do for cross-compartment wrappers and avoids
problems with running jobs against a dying global (Gecko drops such jobs).
I added a globalOfFirstJobInQueue() shell function so I could write a test that
checks both the compartment-per-global and single-compartment cases.
Differential Revision: https://phabricator.services.mozilla.com/D15176
--HG--
extra : moz-landing-system : lando
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
