This also moves the 'mach' docs from /python/mach to /mach. The reason being
that 'mach' doesn't really have anything to do with Python other than its
implemented in it.
Differential Revision: https://phabricator.services.mozilla.com/D52253
--HG--
extra : moz-landing-system : lando
The `setCompositionRecording` API on nsIDOMWindowUtils has been broken up into
two new APIs:
* `startCompositionRecording()`, which starts the composition recorder; and
* `stopCompositionRecording(bool writeToDisk)` which stops the composition
recorder and either returns a Promise that resolves to the collected frames
or returns a Promise that resolves when the frames have been written to disk.
The collected frames are serialized over IPC as part of a Shmem as to not
approach the IPC data transfer limit.
Differential Revision: https://phabricator.services.mozilla.com/D47818
--HG--
extra : moz-landing-system : lando
`windowUtils.setCompositionRecording()` now returns a promise that is resolved
when the composition recorder is enabled (if given `true`) or when frames are
written to disk (if given `false`). To accomplish this, the
`WebRenderCompositionRecorder` now returns a `MozPromise` when writing frames
to disk begins that is resolved when that process finishes.
Differential Revision: https://phabricator.services.mozilla.com/D47300
--HG--
extra : moz-landing-system : lando
Most of these tests relied on assumptions that were broken by the updated
content event helpers (timing, being in a ContentTask, etc).
Depends on D51441
Differential Revision: https://phabricator.services.mozilla.com/D51442
--HG--
extra : moz-landing-system : lando
We fail this during test_invalid_mime_type_blob.html when using DocumentChannel for blobs without this.
DocumentChannelChild reports an internal redirect as it replaces itself with the real channel (BlobURLChannel), and we fail the CheckLoadURIWithPrincipal checks.
The old channel has a null principal (due to being a sandboxed iframe), and we compare that to the blob principal computed from the URI, which is a normal content principal.
Differential Revision: https://phabricator.services.mozilla.com/D51905
--HG--
extra : moz-landing-system : lando
When ReadSegments is called before the stream is ready, we return NS_BASE_STREAM_WOULD_BLOCK, not NS_ERROR_NOT_IMPLEMENTED.
If callers use AsyncWait for the IPCBlobInputStream to be ready, and then call ReadSegments again we can end up returning NS_ERROR_NOT_IMPLEMENTED, depending on what the inner type is.
Differential Revision: https://phabricator.services.mozilla.com/D51781
--HG--
extra : moz-landing-system : lando
Fix `MediaSegmentBase::RemoveTrailing` to be able to accept the first argument, keep frames, equal to zero. The patch avoids calling the `AudioChunk::SliceTo()` method with zero slice duration which hits an assert. The crash was being triggered when in the AudioSegment was including one or more chunks, with the first chunk containing silence (null). Then the `AudioSegment::FlushAfter` had to be called with a duration smaller or equal to the duration of the first chunk. A unit test has been created, verifying the duration of the final segment.
Differential Revision: https://phabricator.services.mozilla.com/D52092
--HG--
extra : moz-landing-system : lando
The AudioSegment::FlushAfter with input argument equals to zero is crashing on an assert that indicates misuse of the AudioChunk::SliceTo method. In general MediaSegmentBase::FlushAfter is better to clear itself when is called with argument equals to zero. This avoids the misuse and it is slightly more efficient.
Differential Revision: https://phabricator.services.mozilla.com/D51862
--HG--
extra : moz-landing-system : lando
When browser.xhtml switches to an <html> root element, the frame structure
changed and caused performance regressions on talos for tart and tresize.
browser.xhtml doesn't need scrolling, so we can disable it and keep performance
on par with XUL <window>.
Differential Revision: https://phabricator.services.mozilla.com/D50675
--HG--
extra : moz-landing-system : lando
Previously we were returning the documentElement in order to match the old XUL behavior.
Now that we have a document.body we can just follow the normal HTML convention.
Differential Revision: https://phabricator.services.mozilla.com/D34021
--HG--
extra : moz-landing-system : lando
The way this test works is, it loads a page, then it navigates to
another page and exits. The mochitest browser-chrome leak detector
will report a leak if the first page isn't freed by the end of the
test.
To make this Fission-compatible, I first changed the page we navigate
to to be same-origin. This means that we won't tear down the original
process immediately when we navigate, which will break the various
test harness stuff.
Secondly, I enable the dom.ipc.keepProcessesAlive.webIsolated
preference, which means that the content process won't be torn down
immediately. If this pref is not set, then the usual process reuse
ends up destroying the window before the test ends, whether or not it
leaks.
I verified that this test fails when the patch from bug 1336811 is
backed out, both with and without Fission.
Differential Revision: https://phabricator.services.mozilla.com/D51944
--HG--
extra : moz-landing-system : lando
Socket Thread and Worker Threads use custom event loops and don't wait in
calls to ProcessNextEvent all the time; this can lead to odd Responsiveness numbers.
Differential Revision: https://phabricator.services.mozilla.com/D51835
--HG--
extra : moz-landing-system : lando
The debug dictionaries in MediaDebugInfo.webidl all have default values, and the intent when the debug structure is created by the C++ promise is to initialize all values, including nested dictionaries, to the provided defaults. **required** was not the right way to do this.
Differential Revision: https://phabricator.services.mozilla.com/D51822
--HG--
extra : moz-landing-system : lando
This can happen when addModule() has not be called, but the thread is created
just to send a NotifyWorkletFinished message.
Differential Revision: https://phabricator.services.mozilla.com/D51925
--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.
3. Mac's implementation of ProxyCreated requires that AddChildDoc be called *before* ProxyCreated so it can invalidate the native children of the parent.
Because it's possible for an OOP iframe document to be added to its embedder after the document is created, we can't satisfy this requirement for OOP iframe documents.
Therefore, we now allow a null parent in Mac's ProxyCreated and use the reorder event fired later to invalidate the native children.
Differential Revision: https://phabricator.services.mozilla.com/D51357
--HG--
extra : moz-landing-system : lando
This was generated with:
```
rg -l -g '*.{cpp,h}' MOZ_XBL . | while read FILE ; do
echo $FILE
unifdef -m -UMOZ_XBL $FILE
done
```
After this, I manually removed the directive in nsContentUtils.cpp due to:
unifdef: ./dom/base/nsContentUtils.cpp: 4630: Unterminated string literal
unifdef: Output may be truncated
Differential Revision: https://phabricator.services.mozilla.com/D51337
--HG--
extra : moz-landing-system : lando
Same underlying reason as the comment before.
Also remove the XBL special case since XBL is no more.
Differential Revision: https://phabricator.services.mozilla.com/D52060
--HG--
extra : moz-landing-system : lando
Also, enable it for the extensions test directory. Without this pref,
it gets frequent intermittent leaks and shutdown hangs when Fission is
enabled.
Differential Revision: https://phabricator.services.mozilla.com/D51752
--HG--
extra : moz-landing-system : lando
Right now, this constant has an equal sign in it. I want to use it in
C++ without the equal sign in the next patch. So, for consistency,
move the equal sign to the places that use this constant. Also, add
the constant to C++.
Differential Revision: https://phabricator.services.mozilla.com/D51751
--HG--
extra : moz-landing-system : lando
So, we don't create a stacking context for this case. Besides, we also
make sure FindAnimationsForCompositor() work properly for motion-path if
offset-path is not effective (i.e. none and no animations).
Differential Revision: https://phabricator.services.mozilla.com/D51895
--HG--
extra : moz-landing-system : lando
The `setCompositionRecording` API on nsIDOMWindowUtils has been broken up into
two new APIs:
* `startCompositionRecording()`, which starts the composition recorder; and
* `stopCompositionRecording(bool writeToDisk)` which stops the composition
recorder and either returns a Promise that resolves to the collected frames
or returns a Promise that resolves when the frames have been written to disk.
The collected frames are serialized over IPC as part of a Shmem as to not
approach the IPC data transfer limit.
Differential Revision: https://phabricator.services.mozilla.com/D47818
--HG--
extra : moz-landing-system : lando
`windowUtils.setCompositionRecording()` now returns a promise that is resolved
when the composition recorder is enabled (if given `true`) or when frames are
written to disk (if given `false`). To accomplish this, the
`WebRenderCompositionRecorder` now returns a `MozPromise` when writing frames
to disk begins that is resolved when that process finishes.
Differential Revision: https://phabricator.services.mozilla.com/D47300
--HG--
extra : moz-landing-system : lando
This fixes the content policy type for document loads in these frames, where
the explicit mIsFrame flag was not set, due to DocShell creation taking a
different code path in remote frames than in in-process frames.
Differential Revision: https://phabricator.services.mozilla.com/D52093
--HG--
extra : moz-landing-system : lando
When ReadSegments is called before the stream is ready, we return NS_BASE_STREAM_WOULD_BLOCK, not NS_ERROR_NOT_IMPLEMENTED.
If callers use AsyncWait for the IPCBlobInputStream to be ready, and then call ReadSegments again we can end up returning NS_ERROR_NOT_IMPLEMENTED, depending on what the inner type is.
Differential Revision: https://phabricator.services.mozilla.com/D51781
--HG--
extra : moz-landing-system : lando
But don't hook it into style yet, that'll be a follow-up patch.
I had this patch in my local queue for a bit and there was no point in not
landing it I guess.
The value of this attribute could be stored only in the shadow root (as this
only applies to shadow hosts), but that would make invalidation harder, I think,
so do the obvious thing for now.
Differential Revision: https://phabricator.services.mozilla.com/D51963
--HG--
extra : moz-landing-system : lando
Increase test cases of activating child frame would also activate its parent frame, no matter the child frame is cross-origin or not.
Differential Revision: https://phabricator.services.mozilla.com/D51691
--HG--
extra : moz-landing-system : lando
In order to reduce the parameters count we send to functions, which can improve readability, we wrap all testing related information to `testInfo`, so that we only need to pass it among different functions.
Differential Revision: https://phabricator.services.mozilla.com/D51687
--HG--
extra : moz-landing-system : lando
In order to create the flexibility of test cases, I separate the creation of iframe and starting media from iframe, and use `play_from` to indicate which frame is the autoplay starts from.
That allows us to to create a test case which contains an iframe but the media is actually played from the parent frame.
Differential Revision: https://phabricator.services.mozilla.com/D51686
--HG--
extra : moz-landing-system : lando
Most of these tests relied on assumptions that were broken by the new content
event utils (timing, being in a ContentTask, etc).
Differential Revision: https://phabricator.services.mozilla.com/D51442
--HG--
extra : moz-landing-system : lando
This change updates the home page to webxr.today for Firefox Realty on Desktop. Further, since WebVR is not supported yet, this change includes a way to disable WebVR specifically for FxR windows without impacting Desktop Fx.
Differential Revision: https://phabricator.services.mozilla.com/D51426
--HG--
extra : moz-landing-system : lando
This is especially important for media elements playing MediaStreams, since the
streams can be manipulated to end playback of the elements synchronously by
either stopping or removing their tracks.
Differential Revision: https://phabricator.services.mozilla.com/D49385
--HG--
extra : moz-landing-system : lando
The Geolocation API specification renamed the following interfaces and removed the [NoInterfaceObject] annotation so that these types are now exposed to script:
* Coordinates -> GeolocationCoordinates
* Position -> GeolocationPosition
* PositionError -> GeolocationPositionError
This is done in response to an effort to remove the [NoInterfaceObject]
annotation from WebIDL.
Additionally, the following interfaces are now only exposed in Secure Contexts:
* GeolocationCoordinates
* GeolocationPosition
Differential Revision: https://phabricator.services.mozilla.com/D51972
--HG--
rename : dom/geolocation/PositionError.cpp => dom/geolocation/GeolocationPositionError.cpp
rename : dom/geolocation/PositionError.h => dom/geolocation/GeolocationPositionError.h
rename : dom/webidl/Coordinates.webidl => dom/webidl/GeolocationCoordinates.webidl
rename : dom/webidl/Position.webidl => dom/webidl/GeolocationPosition.webidl
rename : dom/webidl/PositionError.webidl => dom/webidl/GeolocationPositionError.webidl
extra : moz-landing-system : lando
On macOS, launch native messaging helper apps with a new "Transparency, Consent, and Control" (TCC) attribution chain using the undocumented disclaim posix_spawn attribute.
Differential Revision: https://phabricator.services.mozilla.com/D48028
--HG--
extra : moz-landing-system : lando
Our policy is to allow video document to autoplay only when it's in the top-level window. However, `docshell::GetInProcessSameTypeRootTreeItem()` is not compatible with Fission so that we are not able to get the top-level document if we are in the remote process.
Therefore, we should use `BrowsingContext` instead, to check if the video document is in the top-level context.
Differential Revision: https://phabricator.services.mozilla.com/D51216
--HG--
extra : moz-landing-system : lando
We can remove isOnlyToplevelInTabGroup entirely since we have
BrowsingContext/BrowsingContextGroup exposed through
chrome-webidl. Checking if a browsing context is the only top level
(auxilliary or otherwise) is only a matter of checking that there
isn't a parent, and that the size of the browsing context group is 1.
Differential Revision: https://phabricator.services.mozilla.com/D46590
--HG--
extra : moz-landing-system : lando
The remaining notification methods are moved in a separate commit. The
files are renamed to `MutationObservers.*` in a follow-up commit.
Depends on D51824
Differential Revision: https://phabricator.services.mozilla.com/D51825
--HG--
extra : moz-landing-system : lando
Makes `nsNodeUtils::CloneAndAdopt` temporarily public. Will be hidden
again in a follow-up commit.
Depends on D51820
Differential Revision: https://phabricator.services.mozilla.com/D51821
--HG--
extra : moz-landing-system : lando
Most of these tests relied on assumptions that were broken by the new content
event utils (timing, being in a ContentTask, etc).
Differential Revision: https://phabricator.services.mozilla.com/D51442
--HG--
extra : moz-landing-system : lando
This change updates the home page to webxr.today for Firefox Realty on Desktop. Further, since WebVR is not supported yet, this change includes a way to disable WebVR specifically for FxR windows without impacting Desktop Fx.
Differential Revision: https://phabricator.services.mozilla.com/D51426
--HG--
extra : moz-landing-system : lando
The current API name is bad: we want it to be read "some background
thread", but it could just as easily be read "a singular background
thread", which would lead people to assume that for:
```
NS_DispatchToBackgroundThread(...);
NS_DispatchToBackgroundThread(...);
```
the dispatched tasks will necessarily run in the order they are
dispatched, which is not the case.
Let's try to head off that interpretation by renaming this function.
Differential Revision: https://phabricator.services.mozilla.com/D51703
--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://phabricator.services.mozilla.com/D51148
- [x] undefined Metal symbols
- [x] missing webrtc headers for IPDL magic - https://phabricator.services.mozilla.com/D51558
- [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] cc mislinking C++ standard library - https://github.com/alexcrichton/cc-rs/pull/455
- [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
On macOS, launch native messaging helper apps with a new "Transparency, Consent, and Control" (TCC) attribution chain using the undocumented disclaim posix_spawn attribute.
Differential Revision: https://phabricator.services.mozilla.com/D48028
--HG--
extra : moz-landing-system : lando
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
I found that this test sometime would fail on the try server, and the reason is that the child document doesn't be activated correctly even if we have called `synthesizeMouseAtCenter()`.
In order to reduce the dependency of other modules, which might affect synthesizing event, we should use `notifyUserGestureActivation` to ensure that we indeed activate the document.
Differential Revision: https://phabricator.services.mozilla.com/D51685
--HG--
extra : moz-landing-system : lando
As `ApproverDocOf()` uses `docshell::GetInProcessSameTypeRootTreeItem()`, which is not compatible in Fission because we are not able to get the top document if we are in the remote process. Therefore, we should check browsering content directly instead, because the user activation state would be sync automatically for each top-level browsing context among different processes.
Differential Revision: https://phabricator.services.mozilla.com/D51427
--HG--
extra : moz-landing-system : lando
There were 3 checks for this preference. Prior to bug 1079355 which ignored the
pref for system principals, the checks were all straightforward pref checks.
The conditionals are somewhat confusing as written. The main idea is the code
inside the blocks only executes if:
- The preference is disabled.
- The RV was success (we don't want to steal error handling, just prevent
success.)
- We're not dealing with the system principal.
As such, I'm removing the full conditional blocks.
Differential Revision: https://phabricator.services.mozilla.com/D51672
--HG--
extra : moz-landing-system : lando
nsIDOMWindow is now an empty interface. There are two references to
nsIDOMWindow::openDialog in comments which needed to be updated. There
were also a few forward declarations of nsIDOMWindow that were unused.
Differential Revision: https://phabricator.services.mozilla.com/D51738
--HG--
extra : moz-landing-system : lando
promise rejection event was enabled by default on 69 (bug 1525554).
We could get rid of this preference.
Differential Revision: https://phabricator.services.mozilla.com/D51491
--HG--
extra : moz-landing-system : lando
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
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
Properly handles NPError reporting and makes sure that, in the case of failure, it does not return junk for the NPObject.
Differential Revision: https://phabricator.services.mozilla.com/D48474
--HG--
extra : moz-landing-system : lando
Spoof dom/dom.properties, layout/xmlparser.properties,
layout/MediaDocument.properties to en-US if needed.
Differential Revision: https://phabricator.services.mozilla.com/D46034
--HG--
extra : moz-landing-system : lando
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 doesn't fix every scenario, as chrome JS can still try to call one of these
methods, which will cause a crash. We would need to move SendLoadURI to PContent
so that chrome JS can navigate arbitrary contexts if we wanted to be certain no
crash occurred.
Unfortunately, chrome JS navigates in-process BrowsingContext objects very
frequently in tests (etc), so we can't make location navigations which don't have
an accessor fail.
I considered making the method just produce an error, rather than doing a
diagnostic assert, but I figured we should make that decision in another bug.
Differential Revision: https://phabricator.services.mozilla.com/D50856
--HG--
extra : moz-landing-system : lando
The JSContext* is already fetched from within GetIncumbentGlobal, so the get is
guaranteed not to fail. This simplifies the callsite, making it easier to call.
Differential Revision: https://phabricator.services.mozilla.com/D50855
--HG--
extra : moz-landing-system : lando
These methods are only callable from the parent process, so it doesn't make
sense to have the method available driectly on BrowsingContext.
Differential Revision: https://phabricator.services.mozilla.com/D50854
--HG--
extra : moz-landing-system : lando
It started progressing as soon as we set up the rendering of the tracks in the
stream, which is too early according to the HTMLMediaElement spec.
Now it starts progressing when we're potentially playing. The difference being
that we now wait for mReadyState to go beyond HAVE_CURRENT_DATA before hooking
up the time progression mechanism.
Differential Revision: https://phabricator.services.mozilla.com/D49354
--HG--
extra : moz-landing-system : lando
This makes all inputs to IsPotentiallyPlayin() Watchable when we're playing a
MediaStream.
Differential Revision: https://phabricator.services.mozilla.com/D49353
--HG--
extra : moz-landing-system : lando
Behind a pref to ensure that we can turn this off pretty easily if it has perf
impact.
I want to leave the repainting stuff to another bug to land separately, to track
potential (though I hope not!) perf regressions more easily.
Differential Revision: https://phabricator.services.mozilla.com/D50704
--HG--
extra : moz-landing-system : lando
Spoof dom/dom.properties, layout/xmlparser.properties,
layout/MediaDocument.properties to en-US if needed.
Differential Revision: https://phabricator.services.mozilla.com/D46034
--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
Add an observer to restart the PVideoBridge connection when GPU process
restarts.
Differential Revision: https://phabricator.services.mozilla.com/D50403
--HG--
extra : moz-landing-system : lando
Combine sVideoBridgeToParentProcess and sVideoBridgeToGPUProcess into one
sVideoBridge. Each producing process, GPU or RDD, is only ever started with one
VideoBridgeChild endpoint. This is enough to get RemoteVideoDecoders in RDD
process to start using GPU memory to send video to compositor over PVideoBridge.
Differential Revision: https://phabricator.services.mozilla.com/D50402
--HG--
extra : moz-landing-system : lando
LaunchRDDProcess() and CreateContentBridge() create a sync creation. Merge the
functions into one function. Keep the IPDL messaging async to avoid adding a
exception for the message being sync.
Differential Revision: https://phabricator.services.mozilla.com/D50400
--HG--
extra : moz-landing-system : lando
Andrew Halberstadt
Noemi Erli
Emma Malysz
Perry Jiang
Barret Rennie
Brian Grinstead
Kashav Madan
Matt Woodrow
Alex Chronopoulos
Brendan Dahl
Andrew McCreight
Thomas Nguyen
Ciure Andrei
Sebastian Streich
Randell Jesup
Tarek Ziadé
Edgar Chen
Karl Tomlinson
James Teh
Emilio Cobos Álvarez
Dorel Luca
Daniel Varga
Boris Chiou
Kris Maglione
Coroiu Cristina
Brian Hackett
Anny Gakhokidze
Olli Pettay
Moritz Birghan
Zibi Braniecki
Alastor Wu
thomasmo
Sebastian Hengst
Andreas Pehrson
Christoph Kerschbaumer
Sid Vishnoi
Haik Aftandilian
Brindusan Cristian
Andreas Farre
Mirko Brodesser
Dana Keeler
Michael Froman
Nathan Froyd
Narcis Beleuzu
Dzmitry Malyshau
Simon Giesecke
Andrew Sutherland
Cosmin Sabou
Yaron Tausky
Nicolas Silva
Mihai Alexandru Michis
Csoregi Natalia
Peter Van der Beken
David Parks
Andrea Marchesini
Alex Catarineu
Nika Layzell
Byron Campen [:bwc]
Andreea Pavel
Dan Glastonbury