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
Rather than constructing an nsIURIFixupInfo from the IPC call return valuess, and then immediately querying the same data, this just use the results directly.
It also moves the firing of "keyword-uri-fixup" observers to the parent process side. As far as I can tell, the only consumer was URIFixupChild, which was also forwarding them to the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D81944
Rather than constructing an nsIURIFixupInfo from the IPC call return valuess, and then immediately querying the same data, this just use the results directly.
It also moves the firing of "keyword-uri-fixup" observers to the parent process side. As far as I can tell, the only consumer was URIFixupChild, which was also forwarding them to the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D81944
Alexandru Michis