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
This patch will do :
- rename `ControlledMediaState` to `MediaPlaybackState`
- rename the related functions
The advantage of doing so :
- more consistent with `MediaAudibleState`
Differential Revision: https://phabricator.services.mozilla.com/D72060
This patch will do :
- replace `boolean` with enum class `MediaAudibleState`
The advantage of doing so :
- It's easier to understand what actually meaning of the parameter we set
Differential Revision: https://phabricator.services.mozilla.com/D72058
This patch will do :
- use current broswing context as a parameter when propagate state change to the chrome process.
The advantage of doing so :
- the chrome process can know which browsing context the state change actually comes from.
---
More details about this change :
Currently, when we propagate any controlled media related states, we would find the top level browsing context first, then pass it through IPC in order to get the correct media controller in the chrome process. However, we have implemented [1] which can find the correct media controller even if we are not passing the top level browsing context.
In addition, in bug1627999, we would like to know which browsing context those states come from. Therefore, we should replace the top browsing context with the current browsing context where controlled media exists.
[1] https://searchfox.org/mozilla-central/rev/41c3ea3ee8eab9ce7b82932257cb80b703cbba67/docshell/base/CanonicalBrowsingContext.cpp#511-515
Differential Revision: https://phabricator.services.mozilla.com/D72056
This patch will do :
- remove the inheritance relationship for `ContentControlKeyEventReceiver` and `ContentMediaAgent` and manually implement the methods we need
- `MediaControlEventListener` will inherit from `ContentControlKeyEventReceiver` directly
The advantage of doing so :
- increase the flexibilty of modification of `ContentMediaAgent` and those modification won't affect other classes inherited from `MediaControlKeysEventListener`
---
More details about this change :
As we would like to extend the class `ContentMediaAgent` and allow the `ContentMediaController` to call its extended method, but if we want to do so in current implementation, the extended method would also affect other classes inherited from `MediaControlKeysEventListener` and that is something we don't want to see.
Considering that, I decided to decouple the inheritance relationship and manually create the function I need (which will be implemented in the next patch)
Differential Revision: https://phabricator.services.mozilla.com/D72054
Now that `BridgedEngine` has been moved to `sync15_traits`, we can
remove `golden_gate_traits` from the tree, and change Golden Gate to
depend on `sync15_traits` directly.
This commit also adds a Cargo feature, `services_sync`, which reflects
the `MOZ_SERVICES_SYNC` config option. In the future, we'll use this
feature to gate implementations of `mozIBridgedSyncEngine`.
Differential Revision: https://phabricator.services.mozilla.com/D72784
