This also fixes test
browser/base/content/test/tabs/browser_navigate_through_urls_origin_attributes.js
which was failing for fission + bfcacheInParent, because about:privatebrowsing
was getting bfcached, and an extra XULFrameLoaderCreated event was firing, when
we were not expecting it.
Differential Revision: https://phabricator.services.mozilla.com/D112441
This should help avoid message ordering issues in the next patches. To ensure
that we're not firing events too early, we now do a "full" restore even if we
don't have form or scroll data, including for about:blank URIs.
This also moves all restore state on the CanonicalBrowsingContext into a
separate `mRestoreState` struct.
Differential Revision: https://phabricator.services.mozilla.com/D110333
This makes it trivial to choose the right BrowserParent to print a
browsing context, by removing the OuterWindowID / FrameLoader
indirections.
Differential Revision: https://phabricator.services.mozilla.com/D112412
Also, make sure we update layout history state from docshell before we load a
new URI, as it might be our last chance to do so before a process swap.
Differential Revision: https://phabricator.services.mozilla.com/D110994
This patch contains a large number of changes around the process switching
mechanism in order to avoid issues which are caused by a mismatched
understanding of the state of the process switch between processes in the
presence of nested event loops.
This includes:
1. The "InFlightProcessId" value is no longer recorded. All remaining uses
were removed in part 1, and the new mechanism tracks this information in
a better way.
2. The current BrowserParent instance is now tracked on
CanonicalBrowsingContext, meaning that logic which needs to work with this
information can now access it without depending on the current
WindowGlobalParent instance.
3. When doing a process switch, the previous host process for the
BrowsingContext is tracked until the process switch is completed, allowing
for future attempts to switch into that process to be delayed until the
previous unload event has finished running.
4. The process switch logic was refactored to simplify some of the
error-handling logic, and share more code between different cases.
Differential Revision: https://phabricator.services.mozilla.com/D110002
This patch contains a large number of changes around the process switching
mechanism in order to avoid issues which are caused by a mismatched
understanding of the state of the process switch between processes in the
presence of nested event loops.
This includes:
1. The "InFlightProcessId" value is no longer recorded. All remaining uses
were removed in part 1, and the new mechanism tracks this information in
a better way.
2. The current BrowserParent instance is now tracked on
CanonicalBrowsingContext, meaning that logic which needs to work with this
information can now access it without depending on the current
WindowGlobalParent instance.
3. When doing a process switch, the previous host process for the
BrowsingContext is tracked until the process switch is completed, allowing
for future attempts to switch into that process to be delayed until the
previous unload event has finished running.
4. The process switch logic was refactored to simplify some of the
error-handling logic, and share more code between different cases.
Differential Revision: https://phabricator.services.mozilla.com/D110002
This URI is intended to reflect the currentURI field on the content nsIDocShell,
and is the value used for getters like `window.location.href`. For most
documents, this generally matches the Document URI on WindowGlobalParent, it
does not match in specific cases such as error pages or when performing a
session restore.
The field is kept up-to-date by listening to `OnLocationChange` notifications
from the content process, and is ignored when the BrowsingContext is loaded in
the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D105559
The name RemotenessChangeState uses same the convention as the related methods, even though there might
not be a remoteness change happening, only a browsing context switch. But the naming
inconsistency exists there even without any bfcache work.
RemotenessChangeState will be renamed to RemotenessChangeOptions in a followup.
Differential Revision: https://phabricator.services.mozilla.com/D105229
The name RemotenessChangeState uses same the convention as the related methods, even though there might
not be a remoteness change happening, only a browsing context switch. But the naming
inconsistency exists there even without any bfcache work.
RemotenessChangeState will be renamed to RemotenessChangeOptions in a followup.
Differential Revision: https://phabricator.services.mozilla.com/D105229
Syncing the container FeaturePolicy across BrowsingContext is actually
a bit more heavy-handed than necessary. We only ever need a container
FeaturePolicy when inheriting a FeaturePolicy in exactly the document
the container contains. Not every process that the tree the container
is a part of. So instead of storing a FeaturePolicy in a synced field,
we manually send it to the correct WindowGlobalChild (which
corresponds to a document) and retrieve it from there.
Differential Revision: https://phabricator.services.mozilla.com/D61479
