This test begins to fail due to a `pip` installation issue after bug 1660351. It's already disabled on macOS (also due to what the comment says is a `pip` installation issue), so it's very possible the custom `requirements.txt` that this test installs is deficient in some way that surfaces in certain `virtualenv`s under certain circumstances. I can't diagnose the failure, but what I have seen is that bug 1659539 will fix that problem entirely with no extra intervention required, so we should be able to re-enable this for Linux (and maybe macOS as well?) when that patch lands.
Differential Revision: https://phabricator.services.mozilla.com/D88653
I did notice this issue while investigating a test failure on
browser/components/contextualidentity/test/browser/browser_serviceworkers.js
The issue seems to be triggered when we are using a preallocated child process
for a call to RemoteWorkerManager::LaunchNewContentProcess, when that happens
we do expect that the new process is going to call RemoteWorkerManager::RegisterActor
once its RemoteWorkerService is being initialized in the new child process,
but when we are reusing a preallocated child process the RemoteWorkerService
was already initialized and RegisterActor was already called while the
remoteType for the child process was still "prealloc".
This patch fix the failure by deferring initializing RemoteWorkerService in
child processes to when we do receive a non "prealloc" remoteType in
ContentChild::RecvRemoteType.
Differential Revision: https://phabricator.services.mozilla.com/D86590
We want to be able to retroactively tell whether a push was a backstop or not.
This patch stores whether or not a push was a "backstop" directly in the
parameters. The optimization strategy now simply returns 'not
params["backstop"]'.
For simplicity, I'm not counting the 'optimized-backstop' as a backstop. It's
unclear if we'll want to be able to detect these types of the pushes in the
future or not, but we can cross that bridge when we get there.
Differential Revision: https://phabricator.services.mozilla.com/D88151
In the past, the 'backstop' optimization was applied to tasks by default across
all projects, even though it only really made sense on autoland. To choose what
would happen on non-autoland branches, we invented this 'remove_on_projects'
concept.
These days, we only apply the backstop optimization in the first place for
autoland. So 'remove_on_projects' is no longer necessary.
Depends on D88149
Differential Revision: https://phabricator.services.mozilla.com/D88150
This patch cleans up some of the backstop strategy names. Specifically:
1. Rename 'full-backstop' -> 'backstop'. The old 'backstop' algorithm was
unused anyway, so there is no conflict. It is also just defined directly in
the decorator rather than using 'Alias'.
So now rather than 'full-backstop' and 'optimized-backstop', it's just
'backstop' and 'optimized-backstop'.
2. Remove 'backstop-X-hours-Y-minutes' strategies, and replace them with
the corresponding 'push-interval-X' strategy.
This means we lose the time component in the 'optimized-backstop'. But it isn't
a problem, because we shouldn't be using a time component there at all anyway
(we should just use it with the 'backstop').
Differential Revision: https://phabricator.services.mozilla.com/D88149
NB: This change breaks the IOUtils.read API, requiring that an options
dictionary is passed as the optional second argument, rather than a number
indicating the max bytes to read. This option is not used out of tests however.
Differential Revision: https://phabricator.services.mozilla.com/D88177
This change introduces a `getChildren` method to the IOUtils interface, which
returns an array of absolute paths pointing to the immediate children of a
directory.
This method should provide equivalent (though not the same) functionality to
iterating directory entries using a new `OS.File.DirectoryIterator`.
Differential Revision: https://phabricator.services.mozilla.com/D87875
This advances the migration by 25% each release, starting in release 83 and
completing in 86. The migration code can be removed in the 86 nightly cycle
(or anytime after that).
Differential Revision: https://phabricator.services.mozilla.com/D88453
Despite looking directly at this code while adding the assertion in bug 1660553, I somehow missed that scripted calls were being attached too early. It's not a problem for Ion, because we only inline `FunCall`/`FunApply` if we're calling the jsnative, but it matters for Warp.
Differential Revision: https://phabricator.services.mozilla.com/D88463
The race occurs when the parent changes the owner process for a BC, but the
child does not know about it and proceeds to call SetCurrentInnerWindowId on a
BC it no longer owns. To fix this, in child process, whenever we call
SetCurrentInnerWindowId on a BC, check that the BC is in process and that the
docshell has not been notified about an upcoming process change.
Differential Revision: https://phabricator.services.mozilla.com/D87934
Creating more than 2 nested iframes is not allowed and is now enforced for
about:blank loads because they now take place via DocumentChannel.
Differential Revision: https://phabricator.services.mozilla.com/D85084
In process selection logic, ensure that we don't use the original URI for
about:blank and instead use the result principal. If the about:blank load has a
null principal, then revert to using the original URI.
Also, remove an extra about:blank load when an nsFrameLoaderOwner is changing
remoteness to prevent races.
Differential Revision: https://phabricator.services.mozilla.com/D85081
This patch enables sandboxed srcdoc loads to take place via DocumentChannel,
and adds mechanisms for enabling unsandboxed ones.
Both unsandboxed srcdoc, and in subsequent patches, about:blank, loads require
that the triggering principal and the principal to inherit point to the same
instance if the load takes place in the same process as where we are inheriting
those principals from. We save those principals on a target browsing context before
we load the URI, and later, when we are deserializing LoadInfoArgs into
LoadInfo in the content process, we retrieve the saved principals if the
current load identifier of the target BC matches the load identifier saved
along with the principals.
We also need to make sure that during a process switch for about:srcdoc load,
we don't use the original URI for about:srcdoc to determine the remote type and
instead we use channel's result principal.
Differential Revision: https://phabricator.services.mozilla.com/D85079
This patch is similar to part 4 but for MediaSessionSupport.
Conversions over to `NativeWeakPtr` are pretty straight forward thanks to the
type system. Basically we take a `NativeWeakPtr`, call `Access()` on it, and
if the accessor is truthy, then we call whatever methods we need to call.
Creation of new pointers is done using `NativeWeakPtrHolder::Attach()` and
detaching of strong references is done by `NativeWeakPtr::Detach()`.
Differential Revision: https://phabricator.services.mozilla.com/D88088
This patch is similar to part 4 but for Android a11y.
Conversions over to `NativeWeakPtr` are pretty straight forward thanks to the
type system. Basically we take a `NativeWeakPtr`, call `Access()` on it, and
if the accessor is truthy, then we call whatever methods we need to call.
Creation of new pointers is done using `NativeWeakPtrHolder::Attach()` and
detaching of strong references is done by `NativeWeakPtr::Detach()`.
Differential Revision: https://phabricator.services.mozilla.com/D87365
This patch is similar to part 4 but for `GeckoEditableSupport`.
Conversions over to `NativeWeakPtr` are pretty straight forward thanks to the
type system. Basically we take a `NativeWeakPtr`, call `Access()` on it, and
if the accessor is truthy, then we call whatever methods we need to call.
Creation of new pointers is done using `NativeWeakPtrHolder::Attach()` and
detaching of strong references is done by `NativeWeakPtr::Detach()`.
Differential Revision: https://phabricator.services.mozilla.com/D87364
These conversions are pretty straight forward thanks to the type system.
Basically we take a `NativeWeakPtr`, call `Access()` on it, and if the
accessor is truthy, then we call whatever methods we need to call.
Creation of new pointers is done using `NativeWeakPtrHolder::Attach()` and
detaching of strong references is done by `NativeWeakPtr::Detach()`.
Differential Revision: https://phabricator.services.mozilla.com/D87363
* Having `AndroidView` and `GeckoViewSupport` as nested classes inside of
`nsWindow` make it impossible to forward declare them. We move those classes
into their own headers. We also move `WindowEvent` into its own header.
* We remove the old `NativePtr` and `WindowPtr` implementations from `nsWindow`
and convert the class definitions in this patch to use the new `NativeWeakPtr`.
* `GeckoViewSupport` had a unique quirk where it was owned by `nsWindow`
instead of its Java counterpart. To make `GeckoViewSupport`'s ownership work
like the other classes that use `NativeWeakPtr` (and to substantially simplify
the implementation of `NativeWeakPtr` itself), I have reversed that: now
`nsWindow` holds a `NativeWeakPtr` to `GeckoViewSupport`, while
`GeckoViewSupport` is owned by its Java counterpart and holds a strong ref to
the `nsWindow`.
* `GeckoViewSupport` no longer inherits from `SupportsWeakPtr`, since using it
with `NativeWeakPtr` provides stronger and safer guarantees.
Differential Revision: https://phabricator.services.mozilla.com/D87362
* We rename the existing `NativePtr` struct to `NativePtrTraits`, as that is
more descriptive of what that code actually does;
* We introduce `NativeWeakPtr` as a smart pointer type that holds a pointer
to an object and allows its access in a thread-safe way. See comments.
* We replace some explicit uses of template types with type deduction via
`auto` and `decltype(auto)`. This allows for more use of forward declarations.
Differential Revision: https://phabricator.services.mozilla.com/D87361
Given the access patterns involved on the native side, I think it is safest
to ensure that this field is access atomically by the VM.
Differential Revision: https://phabricator.services.mozilla.com/D87360
config.guess infers information about the compiler using environment
variables, such as CC. However, we use such environment variables to
configure the tooling for the target.
Differential Revision: https://phabricator.services.mozilla.com/D88085
