nsXULWindow is no longer XUL specific and is somewhat confusing name.
Differential Revision: https://phabricator.services.mozilla.com/D51486
--HG--
rename : xpfe/appshell/nsXULWindow.cpp => xpfe/appshell/AppWindow.cpp
rename : xpfe/appshell/nsXULWindow.h => xpfe/appshell/AppWindow.h
rename : xpfe/appshell/nsIXULWindow.idl => xpfe/appshell/nsIAppWindow.idl
extra : moz-landing-system : lando
nsWebShellWindow is the only class that extends nsXULWindow and only
nsWebShellWindows are ever instantiated.
Differential Revision: https://phabricator.services.mozilla.com/D51155
--HG--
extra : moz-landing-system : lando
This way we get the correct values for start-up prefs in the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D51061
--HG--
extra : moz-landing-system : lando
The issue was in commands.js evaluateJSAsync function where
we were trying to use an undefined parameter.
The regression wasn't spotted earlier because we only have
mocha test for CSS warning, and they don't assert this
codepath.
A mochitest is added on this patch to ensure CSS Warnings
can be expanded, that they display the impacted elements
as expected, and that clicking on the icon selects the
expected element in the inspector.
Differential Revision: https://phabricator.services.mozilla.com/D51627
--HG--
extra : moz-landing-system : lando
1. When creating a DocAccessibleParent for an embedded document in an OOP iframe, it's possible that the embedder accessible hasn't been set yet.
This can occur if the iframe is initially hidden.
Previously, we incorrectly set the document up as a top level document (e.g. tab document) in this case.
Now, we set up the document as top level in its content process, set up the proxy, etc.
The document will be added to its child document later when the embedder is set.
2. When setting the embedder accessible for an OOP iframe, check if the embedded DocAccessibleParent already exists.
This can happen if an iframe is hidden and then shown or an iframe is reflowed by layout.
If it already exists, add the embedded (child) document to its embedder.
Differential Revision: https://phabricator.services.mozilla.com/D51357
--HG--
extra : moz-landing-system : lando
This change vendors `wgpu` library in-tree and hooks up the initialization bits. It implements adapter and device initialization and adds a simple test.
Current status:
- [x] Architecture
- [x] figure out the IPC story
- [ ] move wgpu crates into a dedicated folder (let's follow up with this)
- [x] Review
- [x] WebIDL changes by DOM peers
- [x] Linux
- [x] avoid depending on spirv_cross - https://github.com/gfx-rs/wgpu/pull/371
- [x] macOS
- [x] due to cross-compiling shaders - https://github.com/gfx-rs/gfx/pull/3047
- [x] need the dependency update
- [x] stop using gcc - https://github.com/SSheldon/rust-objc-exception/pull/5
- [x] unexpected SSL header collision - https://bugzilla.mozilla.org/show_bug.cgi?id=1592398
- [x] undefined Metal symbols
- [x] Windows
- [x] due to "ipc-channel" not supporting Windows yet - https://github.com/servo/ipc-channel/pull/233~~
- [x] due to some exceptional stuff - https://github.com/grovesNL/spirv_cross/issues/121
- [x] undefined symbol: `D3D12CreateDevice`
- [x] d3d12.dll is not found, dxgi1_4 doesn't present
- [x] d3d11.dll and dxgi.dll need to be explicitly loaded on win32 mingw - https://github.com/gfx-rs/gfx/pull/3076
- [x] libbacktrace fails to link on win32 mingw
- [x] Android
- [x] spirv-cross fails to build - https://github.com/KhronosGroup/SPIRV-Cross/pull/1193
Update-1:
We decided to go with IPDL mechanism instead of Rust based ipc-channel (or any alternatives), which unblocks Windows build.
Update-2:
It appears that WebGPUThreading isn't needed any more as the child thread (and its event loop) is now managed by IPDL infrastructure. This PR removes it 🎉 .
Update-3:
InstanceProvider is also removed.
Update-4:
All set, the try is green, waiting for dependent changes to go in.
Differential Revision: https://phabricator.services.mozilla.com/D49458
--HG--
rename : dom/webgpu/Adapter.cpp => dom/webgpu/ipc/WebGPUTypes.h
rename : third_party/rust/arrayvec/.cargo-checksum.json => third_party/rust/arrayvec-0.4.11/.cargo-checksum.json
rename : third_party/rust/arrayvec/Cargo.toml => third_party/rust/arrayvec-0.4.11/Cargo.toml
rename : third_party/rust/arrayvec/README.rst => third_party/rust/arrayvec-0.4.11/README.rst
rename : third_party/rust/arrayvec/benches/extend.rs => third_party/rust/arrayvec-0.4.11/benches/extend.rs
rename : third_party/rust/arrayvec/build.rs => third_party/rust/arrayvec-0.4.11/build.rs
rename : third_party/rust/arrayvec/src/array.rs => third_party/rust/arrayvec-0.4.11/src/array.rs
rename : third_party/rust/arrayvec/src/array_string.rs => third_party/rust/arrayvec-0.4.11/src/array_string.rs
rename : third_party/rust/arrayvec/src/char.rs => third_party/rust/arrayvec-0.4.11/src/char.rs
rename : third_party/rust/arrayvec/src/lib.rs => third_party/rust/arrayvec-0.4.11/src/lib.rs
rename : third_party/rust/arrayvec/src/maybe_uninit.rs => third_party/rust/arrayvec-0.4.11/src/maybe_uninit.rs
rename : third_party/rust/arrayvec/src/maybe_uninit_nodrop.rs => third_party/rust/arrayvec-0.4.11/src/maybe_uninit_nodrop.rs
rename : third_party/rust/arrayvec/src/maybe_uninit_stable.rs => third_party/rust/arrayvec-0.4.11/src/maybe_uninit_stable.rs
rename : third_party/rust/arrayvec/src/range.rs => third_party/rust/arrayvec-0.4.11/src/range.rs
rename : third_party/rust/arrayvec/tests/serde.rs => third_party/rust/arrayvec-0.4.11/tests/serde.rs
rename : third_party/rust/arrayvec/tests/tests.rs => third_party/rust/arrayvec-0.4.11/tests/tests.rs
rename : third_party/rust/core-graphics/Cargo.toml => third_party/rust/atom/Cargo.toml
rename : third_party/rust/core-graphics/Cargo.toml => third_party/rust/cocoa/Cargo.toml
rename : third_party/rust/core-graphics/src/lib.rs => third_party/rust/cocoa/src/lib.rs
rename : third_party/rust/core-graphics/Cargo.toml => third_party/rust/colorful/Cargo.toml
rename : third_party/rust/core-graphics/Cargo.toml => third_party/rust/range-alloc/Cargo.toml
rename : third_party/rust/core-graphics/Cargo.toml => third_party/rust/shared_library/Cargo.toml
rename : third_party/rust/core-graphics/Cargo.toml => third_party/rust/x11/Cargo.toml
extra : moz-landing-system : lando
1. When creating a DocAccessibleParent for an embedded document in an OOP iframe, it's possible that the embedder accessible hasn't been set yet.
This can occur if the iframe is initially hidden.
Previously, we incorrectly set the document up as a top level document (e.g. tab document) in this case.
Now, we set up the document as top level in its content process, set up the proxy, etc.
The document will be added to its child document later when the embedder is set.
2. When setting the embedder accessible for an OOP iframe, check if the embedded DocAccessibleParent already exists.
This can happen if an iframe is hidden and then shown or an iframe is reflowed by layout.
If it already exists, add the embedded (child) document to its embedder.
Differential Revision: https://phabricator.services.mozilla.com/D51357
--HG--
extra : moz-landing-system : lando
This change vendors `wgpu` library in-tree and hooks up the initialization bits. It implements adapter and device initialization and adds a simple test.
Current status:
- [x] Architecture
- [x] figure out the IPC story
- [ ] move wgpu crates into a dedicated folder (let's follow up with this)
- [x] Review
- [x] WebIDL changes by DOM peers
- [x] Linux
- [x] avoid depending on spirv_cross - https://github.com/gfx-rs/wgpu/pull/371
- [x] macOS
- [x] due to cross-compiling shaders - https://github.com/gfx-rs/gfx/pull/3047
- [x] need the dependency update
- [x] stop using gcc - https://github.com/SSheldon/rust-objc-exception/pull/5
- [x] unexpected SSL header collision - https://bugzilla.mozilla.org/show_bug.cgi?id=1592398
- [x] undefined Metal symbols
- [x] Windows
- [x] due to "ipc-channel" not supporting Windows yet - https://github.com/servo/ipc-channel/pull/233~~
- [x] due to some exceptional stuff - https://github.com/grovesNL/spirv_cross/issues/121
- [x] undefined symbol: `D3D12CreateDevice`
- [x] d3d12.dll is not found, dxgi1_4 doesn't present
- [x] d3d11.dll and dxgi.dll need to be explicitly loaded on win32 mingw - https://github.com/gfx-rs/gfx/pull/3076
- [x] libbacktrace fails to link on win32 mingw
- [x] Android
- [x] spirv-cross fails to build - https://github.com/KhronosGroup/SPIRV-Cross/pull/1193
Update-1:
We decided to go with IPDL mechanism instead of Rust based ipc-channel (or any alternatives), which unblocks Windows build.
Update-2:
It appears that WebGPUThreading isn't needed any more as the child thread (and its event loop) is now managed by IPDL infrastructure. This PR removes it 🎉 .
Update-3:
InstanceProvider is also removed.
Update-4:
All set, the try is green, waiting for dependent changes to go in.
Differential Revision: https://phabricator.services.mozilla.com/D49458
--HG--
rename : dom/webgpu/Adapter.cpp => dom/webgpu/ipc/WebGPUTypes.h
rename : third_party/rust/arrayvec/.cargo-checksum.json => third_party/rust/arrayvec-0.4.11/.cargo-checksum.json
rename : third_party/rust/arrayvec/Cargo.toml => third_party/rust/arrayvec-0.4.11/Cargo.toml
rename : third_party/rust/arrayvec/README.rst => third_party/rust/arrayvec-0.4.11/README.rst
rename : third_party/rust/arrayvec/benches/extend.rs => third_party/rust/arrayvec-0.4.11/benches/extend.rs
rename : third_party/rust/arrayvec/build.rs => third_party/rust/arrayvec-0.4.11/build.rs
rename : third_party/rust/arrayvec/src/array.rs => third_party/rust/arrayvec-0.4.11/src/array.rs
rename : third_party/rust/arrayvec/src/array_string.rs => third_party/rust/arrayvec-0.4.11/src/array_string.rs
rename : third_party/rust/arrayvec/src/char.rs => third_party/rust/arrayvec-0.4.11/src/char.rs
rename : third_party/rust/arrayvec/src/lib.rs => third_party/rust/arrayvec-0.4.11/src/lib.rs
rename : third_party/rust/arrayvec/src/maybe_uninit.rs => third_party/rust/arrayvec-0.4.11/src/maybe_uninit.rs
rename : third_party/rust/arrayvec/src/maybe_uninit_nodrop.rs => third_party/rust/arrayvec-0.4.11/src/maybe_uninit_nodrop.rs
rename : third_party/rust/arrayvec/src/maybe_uninit_stable.rs => third_party/rust/arrayvec-0.4.11/src/maybe_uninit_stable.rs
rename : third_party/rust/arrayvec/src/range.rs => third_party/rust/arrayvec-0.4.11/src/range.rs
rename : third_party/rust/arrayvec/tests/serde.rs => third_party/rust/arrayvec-0.4.11/tests/serde.rs
rename : third_party/rust/arrayvec/tests/tests.rs => third_party/rust/arrayvec-0.4.11/tests/tests.rs
rename : third_party/rust/core-graphics/Cargo.toml => third_party/rust/atom/Cargo.toml
rename : third_party/rust/core-graphics/Cargo.toml => third_party/rust/cocoa/Cargo.toml
rename : third_party/rust/core-graphics/src/lib.rs => third_party/rust/cocoa/src/lib.rs
rename : third_party/rust/core-graphics/Cargo.toml => third_party/rust/colorful/Cargo.toml
rename : third_party/rust/core-graphics/Cargo.toml => third_party/rust/range-alloc/Cargo.toml
rename : third_party/rust/core-graphics/Cargo.toml => third_party/rust/shared_library/Cargo.toml
rename : third_party/rust/core-graphics/Cargo.toml => third_party/rust/x11/Cargo.toml
extra : moz-landing-system : lando
This code is compiled when `MOZ_NEW_CERT_STORAGE` is not defined, which is the
case on beta.
Differential Revision: https://phabricator.services.mozilla.com/D51559
--HG--
extra : moz-landing-system : lando
A speculative fix for intermittent android reftest failures in which the reftest log file
is incomplete but the missing logging is found in the logcat: I hope that closing the
log file explicitly will ensure logging is flushed before the application quits.
Differential Revision: https://phabricator.services.mozilla.com/D51695
--HG--
extra : moz-landing-system : lando
This change defines UNICODE for building vrhost so that wide chars can be sent from vrhost to Firefox.
Differential Revision: https://phabricator.services.mozilla.com/D51470
--HG--
extra : moz-landing-system : lando
Instead, this patch introduces a new `ObjLiteral` mini-bytecode format
that is used to carry object-literal information from parse time to a
later time at which GC objects are safe to allocate. The mini-bytecode simply
specifies a list of fields and constant field values.
The original intent of this patch (realized in previous versions of it)
was to make this an opcode, and completely replace object creation
sequences (NEWINIT, INITPROP, INITPROP, ...) with one OBJLITERAL opcode.
However, there are quite a few performance regressions that occur when
replacing the finely-tuned set of optimizations around this with a new
mechanism.
As a result, this patch only defers allocation of the objects until the
very end of parse. Each object literal adds an ObjLiteralCreationData
instance to the GC-things list, and when the GC-things list is processed
to perform deferred allocations, the described objects will be created.
Differential Revision: https://phabricator.services.mozilla.com/D47985
--HG--
extra : moz-landing-system : lando
Some crashtests call window.location.reload one or more times. Each time the test document loads we call OnDocumentLoad, and each call of that function can lead to a RecordResult call, either directly or indirectly through WaitForTestEnd and its MakeProgress state machine.
Although the error when this happens ("program error managing timeouts") is confusing I found a couple intermittent instances of this happening in our bugzilla.
However with the fission changes to the reftest harness (which in general make things more async) this is much more common because we keep the tests alive longer before tearing down the test page, giving it more of a chance to happen.
To fix it we pass around the top level test url so it can make its way to RecordResult. This means we can ignore RecordResult calls for previous tests, and ignore the second or more RecordResult call for the current test. We reset the count when we start a new test.
Differential Revision: https://phabricator.services.mozilla.com/D51342
--HG--
extra : moz-landing-system : lando