In this bug we're moving away from monolithic JNI headers to class-specific
headers so that we don't have to rebuild the world every time we make a change
to a JNI interface.
Differential Revision: https://phabricator.services.mozilla.com/D75373
This patch will do :
- make all functions which are used to update information from the content process become a part of `IMediaInfoUpdater`
The advantage of doing so :
- It's clear to use `IMediaInfoUpdater` as the only surface to update the media related status
- explictly restrict which functions are available which can avoid using control related functions on those situations
Differential Revision: https://phabricator.services.mozilla.com/D73489
This patch will do :
- move the logic of determining `actual playback state` to `MediaSessionController`
The advantage of doing so :
- increate the cohesion of `MediaSessionController` because it should be the class to determine the final playback status, not `MediaController`
Differential Revision: https://phabricator.services.mozilla.com/D73488
This patch will do :
- move the instance of `MediaPlaybackStatus` to the `MediaSessionController` to allow `MediaSessionController` handle all media related status
The advantage of doing so :
- encapsulate all media related status details to `MediaSessionController` and simplify the code in `MediaController`
Differential Revision: https://phabricator.services.mozilla.com/D73487
This patch will do :
- make `NotifyMediaPlaybackChanged` and `NotifyMediaAudibleChanged` accept one more paramter that indicates where those update come from
The advantage of doing so :
- we would use that to maintain separated media status for each different context in the future patch.
Differential Revision: https://phabricator.services.mozilla.com/D72471
This enables navigating by index in session history go through the
session history in the parent (if enabled with the pref).
If the pref is enabled, then ChildSHistory::Go will send an IPC message
to the parent with the index to navigate to. The parent calls the
existing nsSHistory implementation and starts the loads, and
asynchronously returns the index that we actually navigated to. The
child process then uses that result to update the session history
implementation in the child process (this part is temporary, while we
have session history both in parent and in child). We also make the
parent send an updated length to the child process over IPC, so that
history.length always the length for the implementation in the parent.
Differential Revision: https://phabricator.services.mozilla.com/D65330
This adds a new implementation of nsISHEntry
(mozilla::dom::SessionHistoryEntry). When session history in the parent
is turned on, we'll instantiate the existing nsSHistory in the parent
process, but it will store entries of this new type. The nsSHistory in
the child process will also be instantiated for now, to avoid breaking
too many assumptions, and we try to keep parent and child
implementations in sync.
mozilla::dom::SessionHistoryEntry stores most of its data in a new
structure (mozilla::dom::SessionHistoryInfo) which can be sent over IPC.
When a load starts through the DocumentChannel we create an entry of
this new type for it in the parent process in
DocumentLoadListener::Open. The SessionHistoryInfo for that entry (with
an associated ID) is then sent over IPC in the RedirectToRealChannelArgs
to the process that does the actual load, where we store it in the
nsDocShell in mLoadingEntry (and mLoadingEntryId). The parent process
keeps track of outstanding loading entries in an array (mLoadingEntries)
in the CanonicalBrowsingContext. When a load finishes the nsDocShell
transfers mLoadingEntry into mActiveEntry, and notifies the parent
process through an IPC message (HistoryCommit) with the id of that
entry. The CanonicalBrowsingContext then removes the entry from the
array and stores it in its mActiveEntry, and adds the entry to the
nsSHistory object.
There are a number of things in this patch that are broken, and a lot of
FIXME comments. However, with the pref turned off things should just be
working as before. The goal is to land this first part, and then iterate
on the new implementation until we can switch over.
Differential Revision: https://phabricator.services.mozilla.com/D65329
This should make the flow of how data gets into the initial WindowContext state
more clear, and allows the setting of initial synced WindowContext fields.
Differential Revision: https://phabricator.services.mozilla.com/D74324
This variant was only used for service workers' openWindow method, which has
been changed to no longer behave in this way, meaning that the type can be
removed. The follow-up simplification of removing
'ContentChild::ProvideWindowCommon', and moving the logic directly into
'BrowserChild' is not done in this bug, and will be done in a follow-up instead.
Differential Revision: https://phabricator.services.mozilla.com/D72935
The 'Id' variant was only used with b2g for remote `mozbrowser`s, and is no
longer relevant. The new code instead uses `PBrowser` directly in all cases.
Differential Revision: https://phabricator.services.mozilla.com/D72933
This variant was only used for service workers' openWindow method, which has
been changed to no longer behave in this way, meaning that the type can be
removed. The follow-up simplification of removing
'ContentChild::ProvideWindowCommon', and moving the logic directly into
'BrowserChild' is not done in this bug, and will be done in a follow-up instead.
Differential Revision: https://phabricator.services.mozilla.com/D72935
The 'Id' variant was only used with b2g for remote `mozbrowser`s, and is no
longer relevant. The new code instead uses `PBrowser` directly in all cases.
Differential Revision: https://phabricator.services.mozilla.com/D72933
This variant was only used for service workers' openWindow method, which has
been changed to no longer behave in this way, meaning that the type can be
removed. The follow-up simplification of removing
'ContentChild::ProvideWindowCommon', and moving the logic directly into
'BrowserChild' is not done in this bug, and will be done in a follow-up instead.
Differential Revision: https://phabricator.services.mozilla.com/D72935
The 'Id' variant was only used with b2g for remote `mozbrowser`s, and is no
longer relevant. The new code instead uses `PBrowser` directly in all cases.
Differential Revision: https://phabricator.services.mozilla.com/D72933
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
Both the deprecated `Screen.lockOrientation` and replacement
`ScreenOrientation.lock` APIs have been updated to make use of a new
`OrientationLock` field on the `BrowsingContext`. This replaces the
storage and use of APIs for this on the root docshell.
In the non fission case things should behave the same, as pending
promises for previous calls to `Screen.lockOrientation` will still be
cancelled in process. If there are `BrowsingContext`s in other
processes though, IPC will be sent to the parent, and then each other
child to cancel them. This should be spec compliant as the spec is
already racy with regards to multiple `lockOrientation` calls.
This new implementation has a little extra IPC than the optimal
implementation would since the root `BrowsingContext`s
`OrientationLock` is set using the normal `SyncedContext` machinery,
rather than combining the `AbortOtherOrientationPendingPromises`
message for a single message.
This commit fixes both Bug 1597413 and Bug 1597443.
Differential Revision: https://phabricator.services.mozilla.com/D70416
This allows us to explicitly specify BrowsingContextGroups when synchronizing
them. A major advantage of this is that it means we can handle an attempt to
create a BrowsingContext with a parent which the content process is unaware of,
which is possible due to changes to the EnsureSubscribed logic in earlier
patches in this stack.
This is OK, because in the case where the content process cannot see its parent,
the parent must be imminently discarding.
Differential Revision: https://phabricator.services.mozilla.com/D71668
The existing infrastructure which stored cached BrowsingContexts on the
BrowsingContextGroup was added before WindowContexts were added, and can cause
racing issues with partially discarded trees during process switches.
Differential Revision: https://phabricator.services.mozilla.com/D71238
This allows us to explicitly specify BrowsingContextGroups when synchronizing
them. A major advantage of this is that it means we can handle an attempt to
create a BrowsingContext with a parent which the content process is unaware of,
which is possible due to changes to the EnsureSubscribed logic in earlier
patches in this stack.
This is OK, because in the case where the content process cannot see its parent,
the parent must be imminently discarding.
Differential Revision: https://phabricator.services.mozilla.com/D71668
Gijs Kruitbosch
Aaron Klotz
Dorel Luca
Kris Maglione
alwu
Csoregi Natalia
Peter Van der Beken
ssengupta
Nika Layzell
Tom Schuster
Henri Sivonen
Razvan Maries
Bogdan Tara
David Teller
Simon Giesecke
Stefan Hindli
Dimi Lee
Steven MacLeod
Andreas Farre
Narcis Beleuzu