Since it involves animation it is hard to test but I managed to come up with a test using large fuzz that I verified would catch regressing the original bug *some* of the time, which is better than no test.
Depends on D69322
Differential Revision: https://phabricator.services.mozilla.com/D69323
--HG--
extra : moz-landing-system : lando
./mach jstests --remote
./mach jit-test --remote
Remove xrange usage as python3 incompatible when running
mach jit-test.
Move device initialization code from js/src/tests/lib/jittests.py
to js/src/tests/lib/remote.py. Make device initialization into a
singleton to prevent multiple attempts to initialize a device.
Initialize device in XULInfoTester and support evaluation of test
predicate conditions using the js shell on the device.
Standardize directory names on android device for both jit-test and jstest.
Add arguments to jstests to support chunking.
Differential Revision: https://phabricator.services.mozilla.com/D69054
--HG--
extra : moz-landing-system : lando
When marshaling a11y calls from the content process, there are quite a lot of cross-thread QueryInterface calls (ipc::mscom::Interceptor::QueryInterfaceTarget).
Some of these are for special COM interfaces like IAgileObject and IFastRundown, which we could just special case in Interceptor::QueryInterface like we do for INoMarshal.
However, it seems there are a lot of other interfaces being queried and it's not clear why.
This patch adds a new HandlerProvider method: IsInterfaceMaybeSupported.
This allows implementations to indicate when there are interfaces which they definitely don't support, allowing the call to be answered without a cross-thread call.
Differential Revision: https://phabricator.services.mozilla.com/D69285
--HG--
extra : moz-landing-system : lando
The test added in this changeset is already fixed by the no-normalization change, but there are probably cases that require the explicit check that this patch adds.
When we were still normalizing the plane normals, the TransformAndClipBounds call in the added test was returning (1023.999878, 1023.999878, 0.000061, 0.000122).
Depends on D68703
Differential Revision: https://phabricator.services.mozilla.com/D68704
--HG--
extra : moz-landing-system : lando
For example, if the clipping rectangle has aClip.X() == 1024, then the normal for the clipping plane induced by the left edge of the clip will now be (1, 0, 0, -1024) rather than (0.0009765620343390458, 0, 0, -0.9999995231631829).
This change is mathematically valid:
- The dot products computed from these vectors become multiplied by planeNormal.Length() (compared to before this patch).
- The sign of the dot products is not affected, so the "intersection with plane" check is not affected:
`if ((nextDot >= 0.0) != (prevDot >= 0.0)) {`
- The value of the dot products is only used to compute `t`, as follows:
`F t = -prevDot / (nextDot - prevDot);`
Here, the length now appears both in the numerator and in the denominator, canceling itself out.
As a result from this change, the existing tests no longer require integer nudging in order to pass.
Depends on D68702
Differential Revision: https://phabricator.services.mozilla.com/D68703
--HG--
extra : moz-landing-system : lando
`ProfileBufferChunkManagerWithLocalLimit` is a chunk manager that enforces a
memory limit in each process.
It is meant to mimic the main way `BlocksRingBuffer` works, so that we can more
easily switch to the new buffer storage without introducing the extra complexity
of inter-process memory coordination yet.
`ProfileBufferChunkManagerWithLocalLimit` will still offer a benefit over
`BlocksRingBuffer`, in that it won't allocate the maximum buffer size
immediately -- speeding the initialization, and hopefully even reducing the
total Firefox memory consumption in short-lived processes.
Differential Revision: https://phabricator.services.mozilla.com/D68770
--HG--
extra : moz-landing-system : lando
As we want to check the metadata from the main controller, we should listen to `main-media-controller-changed` notification to ensure that we get the metadata from the correct controller. Otherwise, it might cause the intermittent failure.
Differential Revision: https://phabricator.services.mozilla.com/D67714
--HG--
extra : moz-landing-system : lando
Video element can start the Picture-in-Picture mode **BEFORE** or **AFTER** we start the listener for the media cotrol, so we have to ensure we always propagate this information to the chrome process via `ContentMediaAgent`.
Differential Revision: https://phabricator.services.mozilla.com/D67712
--HG--
extra : moz-landing-system : lando
We would like to ensure that the controller being used in Picture-in-Picture mode can always be the main controller, which means even if there are other controllers starting later than PIP video, they are not able to become the main controller, but we would still maintain a correct order of controllers that can ensure that the main controller can be selected correctly after current main controller get destroyed.
For example, we have a list `[A, B, C]` and `C` is the main controller. And `D` is new coming controller, then the list would become `[A, B, D, C]` and `C` is still the main controller. But if `C` gets destroyed, the list would become `[A, B, D]` and `D` is the main controller.
Differential Revision: https://phabricator.services.mozilla.com/D67710
--HG--
extra : moz-landing-system : lando
Pick commits:
- 432259a: Run `cargo fmt`
- c9f0499: Revert `derive(Debug)` removal (#75)
- f9abca8: Replace the custom input linear buffer by something based on ringbuf. (#74)
- 4eafcc8: Fix the resampler-calling code to use the correct semantic (#71)
- 828efbc: Merge pull request #72 from ChunMinChang/rm-debug-trait
Differential Revision: https://phabricator.services.mozilla.com/D69250
--HG--
extra : moz-landing-system : lando
This commit clarifies that only some OS-level allocations are covered; the old
wording made it sound like they all were.
It also moves the allocator-level allocations first in the list, because
they're more common.
Depends on D43842
Differential Revision: https://phabricator.services.mozilla.com/D69287
--HG--
extra : moz-landing-system : lando
It probably doesn't case any problems because the two callers of the function don't hit the case with the bug.
nsLayoutUtils::TransformRootPointToFrame passes nullptr for the ancester frame.
nsIFrame::GetContentOffsetsFromPoint only calls this function if aFrame is in an svg text subtree, so it takes the other branch.
Looks like this was a simple oversight in this change
https://hg.mozilla.org/mozilla-central/rev/204b51a6c6458a30be158a3d1bdca8e9b4edfd67
where TransformRootPointToFrame was changed to TransformAncestorPointToFrame and it originally passed nullptr (which was correct to the Root version fo the function) but didn't get updated in the change.
Differential Revision: https://phabricator.services.mozilla.com/D68954
--HG--
extra : moz-landing-system : lando
The builds that should be doing LTO now all have PGO+LTO enabled through
taskcluster, and the others shouldn't be wasting time doing LTO.
Differential Revision: https://phabricator.services.mozilla.com/D69174
--HG--
extra : moz-landing-system : lando
I didn't add an automated test as it's a trivial change without existing telemetry tests and I want to replace this histogram with event telemetry soon anyways.
Differential Revision: https://phabricator.services.mozilla.com/D69280
--HG--
extra : moz-landing-system : lando
Timothy Nikkel
Florin Strugariu
sotaro
Emilio Cobos Álvarez
Logan Smyth
Bob Clary
Morgan Reschenberg
James Teh
Mark Striemer
Markus Stange
Gerald Squelart
Ciure Andrei
Botond Ballo
alwu
Chun-Min Chang
Bert Peers
Matt Woodrow
David Walsh
Nicholas Nethercote
aarushivij
Bogdan Tara
Mike Hommey
Martin Thomson
Dragana Damjanovic
Matthew Noorenberghe
Jan-Ivar Bruaroey
Gijs Kruitbosch
Cosmin Sabou