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
Avoid unnecessary IPC traffic by checking if URI's meet the history criteria before sending them to the parent with SendVisitURI.
Differential Revision: https://phabricator.services.mozilla.com/D70217
`UniquePtr` doesn't allow assignment from raw pointers so we update callsites appropriately:
- Assignment from `new` is mapped to `MakeUnique`
- Assignment from pointer params or factory functions ware wrapped with `WrapUnique`
- Assignment from `release` calls are switched to `std::move`
Additionally standalone release calls are piped into `mozilla::Unused` to stifle warnings and document that dropping the pointer is intentional.
Differential Revision: https://phabricator.services.mozilla.com/D72438
`UniquePtr` doesn't provide access to the address of the raw pointer. This swaps out usage of `StartAssignment` to just point to the containers themselves.
Differential Revision: https://phabricator.services.mozilla.com/D72437
The first part of a larger conceptual change to switch XSLT over to `UniquePtr`. This part just replaces the `nsAutoPtr` includes.
Differential Revision: https://phabricator.services.mozilla.com/D72434