I don't think we need these to be done at different times, since the set of checks that happen before uri fixup are error codes that won't be affected by fixup.
Differential Revision: https://phabricator.services.mozilla.com/D80107
This is only used by Thunderbird, and is always true for Firefox. I've made CanSet only allow the embedder process, which is the desired behaviour, and should work for non-e10s.
Differential Revision: https://phabricator.services.mozilla.com/D80109
I don't think we need these to be done at different times, since the set of checks that happen before uri fixup are error codes that won't be affected by fixup.
Differential Revision: https://phabricator.services.mozilla.com/D80107
The moves all decisions to perform a process switch into the DocumentLoadListerner. This removes the unnecessary need to go via a content process to start the load.
Differential Revision: https://phabricator.services.mozilla.com/D76315
This removes all docshell nsISecureBrowserUI and mixed content properties, and moves them into CanonicalBrowsingContext/WindowGlobalParent. It makes the mixed content blocker just compute the state for the current load, and then send the results to the parent process, where we update the security state accordingly.
I think we could in the future remove onSecurityChange entirely, and instead just fire an event to the <browser> element notifying it of changes to the queryable securityUI.
Unfortunately we have a lot of existing code that depends on specific ordering between onSecurityChange and onLocationChange, so I had to hook into the RemoteWebProgress implementation in BrowserParent to mimic the same timings.
Differential Revision: https://phabricator.services.mozilla.com/D75447
This removes all docshell nsISecureBrowserUI and mixed content properties, and moves them into CanonicalBrowsingContext/WindowGlobalParent. It makes the mixed content blocker just compute the state for the current load, and then send the results to the parent process, where we update the security state accordingly.
I think we could in the future remove onSecurityChange entirely, and instead just fire an event to the <browser> element notifying it of changes to the queryable securityUI.
Unfortunately we have a lot of existing code that depends on specific ordering between onSecurityChange and onLocationChange, so I had to hook into the RemoteWebProgress implementation in BrowserParent to mimic the same timings.
Differential Revision: https://phabricator.services.mozilla.com/D75447
The moves all decisions to perform a process switch into the DocumentLoadListerner. This removes the unnecessary need to go via a content process to start the load.
Differential Revision: https://phabricator.services.mozilla.com/D76315
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 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
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
Implemecurnt a flag `suspendMediaWhenInactive` on the docShell that indicates media in that shell should be suspended when the shell is inactive. Currently, only GeckoView is using this flag.
---
The reason of implementing this flag is because in bug1577890 we remove the old way to suspend/resume the media, and I thought setting docshell to inactive is enough to suspend the media because we already have a mechanism which would suspend/resume media when document becomes inactive/active [1].
However, the active state of document is actually different from what I thought it was. Setting docshell to inactive won't change the document's active state, because that indicates if the document is the current active document for the docshell [2] (docshell can have multiple documents), instead of indicating if the docshell is active or not.
Therefore, we have to add another flag to indicate if the docshell wants to suspend its media when it's inactive, in order to use current mechanism to suspend/resume media.
[1] https://searchfox.org/mozilla-central/rev/4d2a9d5dc8f0e65807ee66e2b04c64596c643b7a/dom/html/HTMLMediaElement.cpp#6453
[2] https://searchfox.org/mozilla-central/rev/4d2a9d5dc8f0e65807ee66e2b04c64596c643b7a/dom/base/Document.h#2627-2633
Differential Revision: https://phabricator.services.mozilla.com/D69669
