This is based on the similar changes for JSOp::Pos (bug 1626297 part 3).
JSOp::Pos and JSOp::ToNumeric are very similar and are now optimized the same
way. Baseline had a fast path for numbers and we now use an IC. The IC should
be faster for BigInt code and has optimizations for string inputs. This will also
give us better type information in Warp.
Differential Revision: https://phabricator.services.mozilla.com/D72333
The pref flip in this bug causes an assertion to fail in
layout/generic/crashtests/1137723-1.html.
Our behavior in that crashtest is so messed up that I can't even begin
to describe it.
That test-case has three-pages, and a link inside a fixed-pos subtree,
which has a ::after pseudo-element.
Via the magic of nsCSSFrameConstructor::ReplicateFixedFrames, we end up
constructing multiple frames, one per page, for the fixed subtree.
We end up with a link with three different ::after pseudo-elements (one
on each page), of which the link only knows about the latest one.
This means that when restyling the link (which was already broken, it
just didn't happen before the prefs), we'd visit the pseudo-element in
some other place of the frame tree we can get a hand on.
Restyling these frames is generally not supported and will do ~nothing,
given the current setup. There's no way to get a hand from the DOM node
to all its replicated frames.
But that's not something I plan to fix for this bug, and this assertion
is blocking me.
Differential Revision: https://phabricator.services.mozilla.com/D72755
We need to use the new Settings() API, instead of the deprecated
FlagsForFile. Though in practice we can just delegate to it and it works
out of the box.
Differential Revision: https://phabricator.services.mozilla.com/D72152
The current way to get outgoing files in Git passes every branch to merge-base, which generates a way too long command that fails on Windows. This patch tries using `git log --not --remotes` instead of passing merge-base value.
Differential Revision: https://phabricator.services.mozilla.com/D71802
This patch will do :
- replace boolean with `MediaPlaybackState` in test.
The advantage of doing so :
- better understanding for the meaning of the input parameter
Differential Revision: https://phabricator.services.mozilla.com/D72090
This patch will do :
- create a helper class on `FakeControlledMedia` and use it to rewrite the test `AudibleChanged`.
Differential Revision: https://phabricator.services.mozilla.com/D72089
This patch will do :
- remove tests which are not correct based on new implementation.
---
More details about this change :
After calling controller's methods, the controller's state won't be changed, it would be changed after the amount of playing media changes, which are depending on other modules and can't be tested here.
- `ChangePlayingStateViaPlayPauseStop` would check state after calling controller's method, which is incorrect.
- `AlwaysInaudibleIfControllerIsNotPlaying` would check audible which also references to controller's state
Differential Revision: https://phabricator.services.mozilla.com/D72088
This patch will do :
- only call `SetGuessedPlayState()` when the amount of playing media changes
The advantage of doing so :
- prevent the situation where the guessed playback state and the actual condition of media playback is different if calling controller's methods not able to affect media playback state
---
More details about this change :
The guessed playback state represents the actual media playback condition, which would be modified in [1], so we use `mPlayingControlledMediaNum` to track how many media is playing in order to determine the final playback state for a tab.
Therefore, we should let the state truly reflecting the condition of media playback. If the controller's method doesn't affect the media playback in the content process, then we would have an inconsistency between the state and the actual condition. Eg. calling `controller.pause()` but somehow the media isn't paused.
In addition, doing this also helps the refactoring I'm doing in the bug1627999.
[1] https://searchfox.org/mozilla-central/source/dom/media/mediacontrol/MediaController.cpp#169-192
Differential Revision: https://phabricator.services.mozilla.com/D72066
This removes the need for FrameForPointOptions::IsRelativeToLayoutViewport,
and makes sure each call site of these functions indicates whether the
input point/rect is in visual or layout coordinates.
Several call sites were passing in layout coordinates without setting the
IsRelativeToLayoutViewport flag, which this patch corrects.
Differential Revision: https://phabricator.services.mozilla.com/D71705
This allows headers which nsLayoutUtils.h includes to use these types without
creating a circular dependency.
As part of this change, the types are also moved into namespace mozilla.
Differential Revision: https://phabricator.services.mozilla.com/D71704
This is the anti-climactic end of the patch series.
I set out in this bug to get this test case to pass with apz.allow_zooming.
It took all these changes to do so without regressing other tests.
Differential Revision: https://phabricator.services.mozilla.com/D69644
This test is failing due to the rounding error described in bug 1627365.
As this is a web platform test, it seems inappropriate to modify the
test itself upstream to avoid a Firefox-specific rounding error.
Differential Revision: https://phabricator.services.mozilla.com/D69641
The idea here is:
* The incoming point comes from WidgetEvent::mRefPoint which is in
visual coordinates.
* Depending on the value of the target RelativeTo parameter, we
may need to convert this to layout coordinates.
* In the fast-path, we do a direct check on the viewport type
and apply the visual-to-layout transform if appropriate.
* In the slow path, we rely on TransformRootPointToFrame() (which
calls GetTransformToAncestor()) to include the visual-to-layout
transform if appropriate, by correctly passing in
ViewportType::Visual as the starting point.
* To make sure we get into TransformRootPointToFrame(), we
set transformFound if we'll be crossing a zoomed content root.
Differential Revision: https://phabricator.services.mozilla.com/D68921
This is the "core" change of the patch series, which causes most
existing layout codepaths to correctly factor in the visual to
layout transform (or its inverse), as long as the callers correctly
propagate it in the correct ViewportType.
Differential Revision: https://phabricator.services.mozilla.com/D68920
This "upgrades" various nsLayoutUtils functions which take as inputs
a set of coordinates and a frame that the coordinates are relative to,
to accept a RelativeTo object instead of a frame.
Most of the patch is just dumb propagation, but the few places where
we use an explicit ViewportType::Visual are important. There are
probably a few other places I've overlooked, but this seems to cover
the important ones that come up commonly.
There are undoubtedly other functions into which we can propagate
RelativeTo, in this patch I've propagated it as far as necessary
for my needs in this bug (mainly GetTransformToAncestor() and
GetEventCoordinatesRelativeTo()).
Differential Revision: https://phabricator.services.mozilla.com/D68919
This is already the case for real input events since that's how they
arrive from APZ, and we are no longer changing the coordinates at
the process boundary.
For synthesized events, a future patch will add layout-to-visual
converions to code that sets mRefPoint as appropriate.
Differential Revision: https://phabricator.services.mozilla.com/D68917
We will be applying and unapplying this transform in many places, and
thinking about those operations as "applying the callback transform" and
"unapplying the callback transform" is not very intuitive, especially since
applying the callback transform involves *un*applying the resolution.
Rather, going forward we will use the terminology "visual coordinates"
and "layout coordinates" and use this function to convert back and forth
between them.
ApplyCallbackTransform() is not renamed here because subsequent patches will
transition its callers to use GetVisualToLayoutTransform() and
ApplyCallbackTransform() will be removed.
Differential Revision: https://phabricator.services.mozilla.com/D68297
This function (and helper functions that wrap it) will be used extensively
throughout layout code, so keeping it in APZCCallbackHelper seems awkward.
nsLayoutUtils would also be a reasonable place but has the downside that
adding a new function to it triggers recompiling the world.
Differential Revision: https://phabricator.services.mozilla.com/D68296
The implementation was already only using the scroll id, so there is no
functional change, but this change will make it easier to new call sites
to come up with the function's inputs.
Differential Revision: https://phabricator.services.mozilla.com/D68277
Note that the propagation of the target guid to places where the transform
will be applied is best-effort at the moment. In particular, the
InputAPZContext will result in the correct guid being available in places
that are called synchronously from the Recv*() functions, but not places
called asynhcronously (e.g. via DelayedFireSingleTapEvent).
To mitigate this, places where the transform is applied fall back on the
RCD-RSF if a guid is not available via InputAPZContext (added in a
subsequent patch).
The cases that this gets wrong are fairly edge casey (it requires (a) an
asynchronous codepath, (b) an event targeting a subframe, and (c) that
subframe having a "could not accept the APZ scroll position" transform),
so we just punt on them for now. If it turns out to be important to handle,
then options for doing so include (1) propagating the guid through each of
the affected asynchronous codepaths, or (2) attaching the guid to the event
itself.
Differential Revision: https://phabricator.services.mozilla.com/D68723
This is to facilitate call sites that need to incorporate the transform into
a larger transform matrix rather than immediately applying the callback
transform to a point.
Differential Revision: https://phabricator.services.mozilla.com/D68275
Prior to this bug, it was necessary to handle non-e10s specially, because the
resolution was being unapplied at the process boundary, and in non-e10s there
was no process boundary.
The remaining patches in this bug move the resolution unapplication away from
the process boundary in all cases, making special handling for non-e10s
unnecessary.
Differential Revision: https://phabricator.services.mozilla.com/D68273
Jan de Mooij
Emilio Cobos Álvarez
Csoregi Natalia
Paul Adenot
Artem
Jon Coppeard
Kagami Sascha Rosylight
Noemi Erli
alwu
Christoph Kerschbaumer
Botond Ballo