This is a rare edge case, but it affects which clips are able to be considered
as shared clips. Fixing this makes the shared clips more likely to be consistent,
which will be important for the follow up patches in this bug. This mostly
only affects Gecko when running with Fission enabled.
Differential Revision: https://phabricator.services.mozilla.com/D90330
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
In the build process, there's two ways that java is used:
* From the path
* From the java-bin-path specified in the mozconfig
Before, to assert that both "java" usages would be consistent, the
implementation assumed that there was only a single "java" binary
per-JDK-version, and all duplicate "binaries" were symlinks to the
original.
However, in Fedora, it has two identical full binaries: one in
$JDK/bin, and one in $JDK/jre/bin. The symlink theory was incorrect.
So instead, we can assert that both "java" usages are consistent
by checking their versions and asserting that they are equivalent.
Differential Revision: https://phabricator.services.mozilla.com/D90918
In a name section of length 0, the first call to DecodeModuleNameSubsection will decode a name
but fail when finishNameSubsection detects the currentOffset is past the declared length of the
section. This failure result will bubble to the finish label of DecodeNameSection and be ignored.
This is okay, but we need to not set the moduleName until the subsection is completely validated.
Differential Revision: https://phabricator.services.mozilla.com/D90514
We don't collect telemetry stats on why users don't get HW ANGLE,
however we can just share failure IDs with HW ANGLE when we disable
WebRender with UnavailableNoAngle.
Differential Revision: https://phabricator.services.mozilla.com/D90867
First, by running all the tests in their own tab reduces the risk
of bad interactions between tests.
Also the legacy element click tests actually never tested the
legacy mode because "moz:webdriverClick" has been set to "true"
by default, but the capability for the tests hasn't been changed
to point to false.
Differential Revision: https://phabricator.services.mozilla.com/D90879
This was disabled temporarily to fix a regression. It was resolved
by 1665805, which fixes an unrelated bug in the CoreAnimation
implementation due to coordinate accuracy.
Differential Revision: https://phabricator.services.mozilla.com/D90799
The conversion was done with c2rust and then manually cleaned up some.
There's still lots of unsafe code remaining but I'd rather do the rest
of the cleanup in-tree so that it's easier to catch and revert
regressions.
I've dropped support for SSE1 (Firefox requires SSE2) and Altivec
(not wanting to deal with fixing Rust's Altivec support).
transform_neon.rs manually implements a bunch of intrinsics, this
can be fixed when we can depend on Rust 1.48.
The fuzz target is changed to a cargo-fuzz target.
Some of the gtests are moved to Rust.
Differential Revision: https://phabricator.services.mozilla.com/D90782
This patch uses the prefs relevant to the pre-xul skeleton UI to control the
registry value. There are three prefs:
- A new pref intended to be the global toggle once all themes can be handled.
- browser.startup.blankWindow - we currently depend on the code in BrowserGlue.jsm,
gated on this pref, which immediately specifies the width and height of the
window and ultimately causes XUL to consume and take ownership of our pre-xul
window. Without this, we resize to fit a small content area, and then resize
again back to the correct size.
- extensions.activeThemeID - Given that we have hardcoded layout and colors, we
need to ensure that we're only presenting the skeleton UI for the default theme.
We're hoping to not need to gate on any prefs other than the new pref that we're
adding, but this allows us to provide a simple direction for users who may want
to dogfood our changes in the mean time: use the default theme, ensure the
browser.startup.blankWindow pref is set, and turn our new pref on.
Differential Revision: https://phabricator.services.mozilla.com/D90884
It crashes if it fails to create the unprivileged junk scope, which is not
great when it's being used by a fallible function.
Differential Revision: https://phabricator.services.mozilla.com/D90753
