This is done using slightly different mechanisms for each of LoadInfo and
nsDocShellLoadState, and will be used in the next part to validate document
loads based on the RemoteType responsible for the load.
For subresource loads, the TriggeringRemoteType is fairly straightforward - it
is the process which created the channel. We can handle this by getting the
current remote type when creating the channel, and then using the remote type
of the sending process when receiving the LoadInfo over IPC to either replace
the triggering remote type, or validate it.
For document loads, the situation is a bit more complex, as there are at least
3 (potentially-)different processes responsible for different parts of the
navigation:
1. The "Triggering Process" is the process which provided the URI to load.
This is also the process which provides the Triggering Principal. This is
the process being tracked in this patch.
2. The "Loading Process" is the process which actually creates the channel and
starts the load. This may be the same as the triggering process, or may be
a different process starting the navigation on behalf of the triggering
process. In general this is the process hosting the current docshell,
though it may be the parent process in the case of parent-initiated loads.
3. The "Final Process" is the process which receives the response and renders
the final document. This isn't known at channel creation time, and is
determined by the result principal and process isolation policy.
This change uses a serializer and special field on nsDocShellLoadState to track
the "Triggering Process" for the load, even as the load state is serialized
between processes by tracking which loads were sent into which content
processes, and matching them up when the parent process sees them again. The
information is then copied into the LoadInfo before configuring the real
channel, so it can be used for security checks.
The "Triggering Process" is overridden to be the parent process for history
loads, as history loads are often started in processes which wouldn't normally
be able to navigate to those pages. This is OK thanks to the changes in part 1
which validate history loads against the real session history when SHIP is
enabled.
Differential Revision: https://phabricator.services.mozilla.com/D161198
Previously, we tracked UnstrippedURI on the nsDocShellLoadState and LoadInfo,
and manually filled it in to match the previous load when doing a
LOAD_CMD_RELOAD in nsDocShell. It is more consistent with other load types to
instead store the information in the load state, allowing it to be handled
consistently for reloads and other history operations.
Unfortunately, this patch has some extra complexity right now, as it needs to
support both SHIP and non-SHIP session history. This should disappear in the
future when we switch to using exclusively SHIP.
Differential Revision: https://phabricator.services.mozilla.com/D161196
Previously, we tracked UnstrippedURI on the nsDocShellLoadState and LoadInfo,
and manually filled it in to match the previous load when doing a
LOAD_CMD_RELOAD in nsDocShell. It is more consistent with other load types to
instead store the information in the load state, allowing it to be handled
consistently for reloads and other history operations.
Unfortunately, this patch has some extra complexity right now, as it needs to
support both SHIP and non-SHIP session history. This should disappear in the
future when we switch to using exclusively SHIP.
Differential Revision: https://phabricator.services.mozilla.com/D161196
Previously, we tracked UnstrippedURI on the nsDocShellLoadState and LoadInfo,
and manually filled it in to match the previous load when doing a
LOAD_CMD_RELOAD in nsDocShell. It is more consistent with other load types to
instead store the information in the load state, allowing it to be handled
consistently for reloads and other history operations.
Unfortunately, this patch has some extra complexity right now, as it needs to
support both SHIP and non-SHIP session history. This should disappear in the
future when we switch to using exclusively SHIP.
Differential Revision: https://phabricator.services.mozilla.com/D161196
When we navigate in history to the same entry that we're current at then we
actually do a reload. The problem is in the way we detect whether to do a reload
in the parent process.
If a page does a back and a forward one after the other in a script, then the
parent will calculate the index for the back and tell the child to load the
entry at that index. While the child is processing the load of that entry, the
BC in the parent process still has the same entry as its active entry (until the
child commits the load of the entry over IPC). The parent then processes the
forward, calculates the index for the forward and finds the entry at that index.
This is the same entry that we were at before doing anything, and so the same
entry as the active entry in the BC in the parent process. We used to compare
the entry that we're going to load with the active entry in the BC to determine
whether we're doing a reload, and so in this situation we would assume the
forward navigation was actually doing a reload. The child would reload the page,
and we'd run the script again and we'd end up in a reload loop.
Comparing the offset with 0 to determine whether we're doing a reload fixes this
issue.
Differential Revision: https://phabricator.services.mozilla.com/D126585
When we navigate in history to the same entry that we're current at then we
actually do a reload. The problem is in the way we detect whether to do a reload
in the parent process.
If a page does a back and a forward one after the other in a script, then the
parent will calculate the index for the back and tell the child to load the
entry at that index. While the child is processing the load of that entry, the
BC in the parent process still has the same entry as its active entry (until the
child commits the load of the entry over IPC). The parent then processes the
forward, calculates the index for the forward and finds the entry at that index.
This is the same entry that we were at before doing anything, and so the same
entry as the active entry in the BC in the parent process. We used to compare
the entry that we're going to load with the active entry in the BC to determine
whether we're doing a reload, and so in this situation we would assume the
forward navigation was actually doing a reload. The child would reload the page,
and we'd run the script again and we'd end up in a reload loop.
Comparing the offset with 0 to determine whether we're doing a reload fixes this
issue.
Differential Revision: https://phabricator.services.mozilla.com/D126585
Using requestedIndex on the child side is hard, because there are race conditions when a session history load is triggered
and at the same time a non-session history load commits a new active entry.
Differential Revision: https://phabricator.services.mozilla.com/D126619
When we navigate in history to the same entry that we're current at then we
actually do a reload. The problem is in the way we detect whether to do a reload
in the parent process.
If a page does a back and a forward one after the other in a script, then the
parent will calculate the index for the back and tell the child to load the
entry at that index. While the child is processing the load of that entry, the
BC in the parent process still has the same entry as its active entry (until the
child commits the load of the entry over IPC). The parent then processes the
forward, calculates the index for the forward and finds the entry at that index.
This is the same entry that we were at before doing anything, and so the same
entry as the active entry in the BC in the parent process. We used to compare
the entry that we're going to load with the active entry in the BC to determine
whether we're doing a reload, and so in this situation we would assume the
forward navigation was actually doing a reload. The child would reload the page,
and we'd run the script again and we'd end up in a reload loop.
Comparing the offset with 0 to determine whether we're doing a reload fixes this
issue.
Differential Revision: https://phabricator.services.mozilla.com/D126585
After the changes in this bug, about:blank loads triggered by chrome will
finish in a "web" content process, as they have an untrusted null principal
without a precursor. In a few places throughout the codebase, however, we
perform about:blank loads with the explicit expectation that they do not change
processes. This new remoteTypeOverride option allows the intended final process
to be explicitly specified in this situation.
For security & simplicity reasons, this new attribute is limited to only be
usable on system-principal triggered loads of about:blank in toplevel browsing
contexts.
Differential Revision: https://phabricator.services.mozilla.com/D120671
After the changes in this bug, about:blank loads triggered by chrome will
finish in a "web" content process, as they have an untrusted null principal
without a precursor. In a few places throughout the codebase, however, we
perform about:blank loads with the explicit expectation that they do not change
processes. This new remoteTypeOverride option allows the intended final process
to be explicitly specified in this situation.
For security & simplicity reasons, this new attribute is limited to only be
usable on system-principal triggered loads of about:blank in toplevel browsing
contexts.
Differential Revision: https://phabricator.services.mozilla.com/D120671
After the changes in this bug, about:blank loads triggered by chrome will
finish in a "web" content process, as they have an untrusted null principal
without a precursor. In a few places throughout the codebase, however, we
perform about:blank loads with the explicit expectation that they do not change
processes. This new remoteTypeOverride option allows the intended final process
to be explicitly specified in this situation.
For security & simplicity reasons, this new attribute is limited to only be
usable on system-principal triggered loads of about:blank in toplevel browsing
contexts.
Differential Revision: https://phabricator.services.mozilla.com/D120671
After the changes in this bug, about:blank loads triggered by chrome will
finish in a "web" content process, as they have an untrusted null principal
without a precursor. In a few places throughout the codebase, however, we
perform about:blank loads with the explicit expectation that they do not change
processes. This new remoteTypeOverride option allows the intended final process
to be explicitly specified in this situation.
For security & simplicity reasons, this new attribute is limited to only be
usable on system-principal triggered loads of about:blank in toplevel browsing
contexts.
Differential Revision: https://phabricator.services.mozilla.com/D120671
After the changes in this bug, about:blank loads triggered by chrome will
finish in a "web" content process, as they have an untrusted null principal
without a precursor. In a few places throughout the codebase, however, we
perform about:blank loads with the explicit expectation that they do not change
processes. This new remoteTypeOverride option allows the intended final process
to be explicitly specified in this situation.
For security & simplicity reasons, this new attribute is limited to only be
usable on system-principal triggered loads of about:blank in toplevel browsing
contexts.
Differential Revision: https://phabricator.services.mozilla.com/D120671
To restore the stripped query parameters when ETP toggle has been set to
off, we preserve the current unstripped URI to the new loadState when
doing a reload. By doing this, it will redirect the channel back to the
unstripped URI because the loading channel is in the content blocking
allow list and it has a unstripped URI in its loadInfo.
Differential Revision: https://phabricator.services.mozilla.com/D116116
This patch adds an attribute UnstrippedURI in the nsDocShellLoadState.
The attribute will be set if the query stripping was happening.
Otherwise, it will stay a nullptr. This attribute will be propagated to
the loadInfo, so that we can revert the query stripping in the parent
process if the loading URI is in the content blocking allow list. We can
only revert the query stripping in the parent process because we cannot
access the permission of the content blocking allow list of a
cross-origin domain. So, we can only carry the unstripped URI in the
loadInfo and perform a interal redirect to revert the query stripping.
Differential Revision: https://phabricator.services.mozilla.com/D116109
The target query parameters will be stripped from the loading URI in
nsDocShell before creating the channel for the loading. We will only
strip the URI for top-level loading but not for frames. It's because
there is no need to strip frames if we've stripped in top-level already.
Differential Revision: https://phabricator.services.mozilla.com/D113843
The check was a bit too general it seems. Explicitly allow moving focus
for link clicks and window.open(), which are the things we have tests
for and care about moving focus.
Differential Revision: https://phabricator.services.mozilla.com/D107039
Per spec, whenever a "beforeunload" event handler which would affect a
`location.reload()` call exists, it must be called before the `reload()` call
returns. If a handler requests to block the navigation and we choose to
display a confirmation prompt, that must also be displayed before the call
returns.
With session history in parent, though, that currently does not happen,
because `location.reload()` triggers an async IPC call to the parent process,
and only attempts the actual reload (and thus beforeunload dispatch and
prompting) once it returns, which is too late to affect the caller.
This patch changes the handling in this case to manually perform permit unload
checks before taking an async code path. This still leaves the opportunity for
session history handlers in the parent to cancel the load asynchronously, but
that doesn't violate any spec-defined behavior.
Differential Revision: https://phabricator.services.mozilla.com/D94354
Checking for an nsISHEntry doesn't work anymore with session history in the
parent. For that we can check that the loading session history info's
mIsLoadFromSessionHistory is true. If there is no loading session history info
we can fall back to the old way of checking for a non-null nsISHEntry (which
will only ever be true if session history in the parent is turned off).
Differential Revision: https://phabricator.services.mozilla.com/D87037
This patch also makes the identifier for channels global, in the sense
that the generated identifier is generated outside of and passed to
the nsIRedirectChannelRegistrar.
Differential Revision: https://phabricator.services.mozilla.com/D79820
