This removes the diagnostic warnings which used to be logged when the
Large-Allocation header was present, but failed to switch into a
Large-Allocation process. Due to the low adoption of the header, this shouldn't
be too large of a problem, but we can look into re-adding the diagnostics if
needed in the future.
The new codepath no longer performs multiple network requests for
Large-Allocation resources, and now relies on the battle-tested
DocumentLoadListener codepath for process switching.
Differential Revision: https://phabricator.services.mozilla.com/D78998
I think at this point we can remove all of RemoteWebProgressManager, some/all of the TabProgressListener recreations, and probably a bunch more.
Differential Revision: https://phabricator.services.mozilla.com/D79240
This removes the diagnostic warnings which used to be logged when the
Large-Allocation header was present, but failed to switch into a
Large-Allocation process. Due to the low adoption of the header, this shouldn't
be too large of a problem, but we can look into re-adding the diagnostics if
needed in the future.
The new codepath no longer performs multiple network requests for
Large-Allocation resources, and now relies on the battle-tested
DocumentLoadListener codepath for process switching.
Differential Revision: https://phabricator.services.mozilla.com/D78998
This has the side effect of fixing support of mozallowfullscreen when
feature policy is enabled, because it checks only AllowFullscreen, which
doesn't check for the moz-prefixed attribute.
I left the swapframeloader bits alone because they're mozbrowser
specific and I have no idea what they're trying to do.
Differential Revision: https://phabricator.services.mozilla.com/D78701
Previously we called DisplayLoadError with NS_ERROR_DOM_BASE_URI for errors detected during AsyncOpen, but not for asynchronous errors, and this patch queue changed when some security errors happen to be asynchronous.
GeckoView has tests that require DisplayLoadError to be called (which allows for a custom error page to be loaded). Unfortunately, doing so breaks existing gecko tests, since the method of detecting a blocked load fails when GeckoView loads a custom error page.
Differential Revision: https://phabricator.services.mozilla.com/D77171
Previously we called DisplayLoadError with NS_ERROR_DOM_BASE_URI for errors detected during AsyncOpen, but not for asynchronous errors, and this patch queue changed when some security errors happen to be asynchronous.
GeckoView has tests that require DisplayLoadError to be called (which allows for a custom error page to be loaded). Unfortunately, doing so breaks existing gecko tests, since the method of detecting a blocked load fails when GeckoView loads a custom error page.
Differential Revision: https://phabricator.services.mozilla.com/D77171
It would otherwise triggers browser/base/content/test/performance/browser_preferences_usage.js
That pref would have been checked with every single load, a staticpref is O-1 .
Differential Revision: https://phabricator.services.mozilla.com/D76317
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
It would otherwise triggers browser/base/content/test/performance/browser_preferences_usage.js
That pref would have been checked with every single load, a staticpref is O-1 .
Differential Revision: https://phabricator.services.mozilla.com/D76317
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
Reinstate customUserAgent interface for nsIDocShell. This is so it can be used
as a choke-point to catch setting values on docshells which are in the process
of changing process. We don't want to send changes which will be rejected on the
parent side.
This code should be removed once callers setting customUserAgent are refactored
to only occur from parent process.
Differential Revision: https://phabricator.services.mozilla.com/D75006
Bug 1598523 added an assertion that if INTERNAL_LOAD_FLAGS_IS_SRCDOC is not set
in a load state's load flags, then the srcdoc must be a void string.
nsDocShell::Reload never set srcdoc to a void string in that case, and wasn't
fixed up.
Differential Revision: https://phabricator.services.mozilla.com/D75908
