The remaining three uint32_t uses in AtomicsObject.h/cpp are unrelated.
This also fixes the byteLength getter on ArrayBuffer and SharedArrayBuffer.
Differential Revision: https://phabricator.services.mozilla.com/D95688
Right now PipeWire is enabled when Wayland session is used regardless of an active Gtk backend (X11/Wayland).
Let's use PipeWire only when Wayland Gtk backend is used and disable it for X11 one to avoid possible regressions.
Differential Revision: https://phabricator.services.mozilla.com/D94588
In bug 1673818 an intermediary getter was introduced for the buffer
length, in anticipation of larger buffers and a distinction between
32-bit and 64-bit wasm memories. This getter asserts that the value
it gets is below the limit for the appropriate memory type, eg,
ByteLength32 asserts that the value it gets is below MaxMemory32Bytes,
which is currently 2^31-64K. However, ArrayBuffers up to 2^31-1 can
be constructed and passed to asm.js, so asm.js must not use this
getter until after it has validated that the buffer length is below
MaxMemory32Bytes.
Thus we use the unchecked byteLength() accessor on the buffer, and
introduce an additional guard in IsValidAsmJSHeapLength that the
length is also a valid wasm length. This will have no impact on
asm.js in SpiderMonkey as the largest valid asm.js length is already
below the wasm maximum. (The largest valid asm.js length is the
largest value below 2^31-1 whose low 24 bits are all zero.)
Differential Revision: https://phabricator.services.mozilla.com/D95563
Introduce a new helper element.isInXULDocument that should be used when we need to infer the context (chrome or content) from a given element.
The existing element.isXULElement is still relevant and should be used to detect actual XUL elements, which need to be handled differently from HTML elements.
Use the new helper isInXULDocument:
- in element.from, to decide to create ChromeWebElement or ContentWebElement for a given node.
- in element.add, to infer the context
Differential Revision: https://phabricator.services.mozilla.com/D94907
The `dom.worker.console.dispatch_events_to_main_thread` pref is used by platform
code to check if console API messages in the worker thread should be dispatched
to the main thread. If so, the message parameters are cloned, or stringified if
they can't be. This is currently the default behavior.
The pref is checked on the server side and added as a trait to the root actor.
On the client, if the pref isn't true, then we accept messages coming from
worker targets in the console. We can't accept them without condition, otherwise
we would get duplicated message (from the main thread AND the worker thread).
The browser_webconsole_console_logging_workers_api.js test is repurposed for
worker logging since it was disabled on e10s anyway. We add a few test case
to check we can get cached and live message, and that non-clonable object, like
worker scope, are displayed like regular objects when the pref is false.
Differential Revision: https://phabricator.services.mozilla.com/D85397
The commonalities of the x64 code generation test cases are factored
into lib/codegen-x64-test.js and that file is included by the test
cases.
The harness allows the expected patterns in the test cases to be much
smaller. The harness adds the pattern prefix and suffix during
preprocessing, adds the address prefix for each line, and makes
whitespace matching more flexible.
Additionally the harness exports some variables (representing
subpatterns) that can be used within the expected patterns to express
common phrases, such as RIP-relative addresses.
Differential Revision: https://phabricator.services.mozilla.com/D95733
In bug 1673818 an intermediary getter was introduced for the buffer
length, in anticipation of larger buffers and a distinction between
32-bit and 64-bit wasm memories. This getter asserts that the value
it gets is below the limit for the appropriate memory type, eg,
ByteLength32 asserts that the value it gets is below MaxMemory32Bytes,
which is currently 2^31-64K. However, ArrayBuffers up to 2^31-1 can
be constructed and passed to asm.js, so asm.js must not use this
getter until after it has validated that the buffer length is below
MaxMemory32Bytes.
Thus we use the unchecked byteLength() accessor on the buffer, and
introduce an additional guard in IsValidAsmJSHeapLength that the
length is also a valid wasm length. This will have no impact on
asm.js in SpiderMonkey as the largest valid asm.js length is already
below the wasm maximum. (The largest valid asm.js length is the
largest value below 2^31-1 whose low 24 bits are all zero.)
Differential Revision: https://phabricator.services.mozilla.com/D95563
Some uses of naked ip0 and ip1 registers really should use the scratch
register scopes to avoid conflict in the Masm, or should have copious
commentary to reason why it is ok not to do so.
This uncovered a minor issue where a register was used while it was
claimed by higher-level code but this was only a scoping bug higher
up, not an actual code bug.
Differential Revision: https://phabricator.services.mozilla.com/D95867
Implemented DMABufSurfaceWrapper and VAAPIDisplayHolder as a versioned class templates
as they are going to be used by both system ffmpeg and bundled ffvpx decoders.
Differential Revision: https://phabricator.services.mozilla.com/D90555
Right now PipeWire is enabled when Wayland session is used regardless of an active Gtk backend (X11/Wayland).
Let's use PipeWire only when Wayland Gtk backend is used and disable it for X11 one to avoid possible regressions.
Differential Revision: https://phabricator.services.mozilla.com/D94588
Tim Huang
Jan de Mooij
smolnar
Philipp Ammann
stransky
Mark Banner
Valentin Gosu
Lars T Hansen
Julian Descottes
Nicolas Chevobbe
Henrik Skupin
Cosmin Sabou
Victor Porof
Edgar Chen
Matt Woodrow
Frederik Braun
alwu