In this patch, we populate the partitionedPrincipal when we commit
SessionHistory to the parent process. In addition, we remove the
serialization and deserialization of partitionedPrincipalToInherit in
sessionHistory.
Differential Revision: https://phabricator.services.mozilla.com/D250263
When redirects are involved, `DocumentLoadListener::DoOnStartRequest`
may call `ReplaceLoadingSessionHistoryEntryForLoad`, which updates the
history entry with the destination of a redirect. But if the redirection
target is a `moz-extension:`-URL, the URL becomes a jar:file:/file: URL.
This is because SessionHistoryInfo (in SessionHistoryEntry.cpp) looks up
the URL with `nsIChannel::GetURI`. For `moz-extension:`-URLs, the
underlying channel has a `jar:file:` or `file:` URL, as provided by
ExtensionProtocolHandler (via SubstitutingProtocolHandler::NewChannel).
For details, see https://bugzilla.mozilla.org/show_bug.cgi?id=1826867#c7
To fix this, this patch switches to `NS_GetFinalChannelURI` instead. For
more history on this type of bug and SessionHistoryInfo, see
https://bugzilla.mozilla.org/show_bug.cgi?id=1826867#c9
Differential Revision: https://phabricator.services.mozilla.com/D234333
Previously we were calling these methods more often than necessary, as they'd
be called multiple times per-BrowserParent if a single BrowserParent is hosting
multiple frames.
Differential Revision: https://phabricator.services.mozilla.com/D229549
`nsDocShellLoadState::IsExemptFromHTTPSOnlyMode` is currently only used by HTTPS-First. It is used for fixing upgrade-downgrade loops and when loading history entries, as when we already know if HTTPS-First succeeded there or not, we have no need for trying to upgrade again and can disable HTTPS-First. With the changes introduced by Bug 1839612, `nsDocShellLoadState::IsExemptFromHTTPSOnlyMode` also applies to HTTPS-Only, which is a problem because disabling HTTPS-Only for history entries will result in them potentially being loaded insecurely without the user setting an exception. As a solution this patch just applies `nsILoadInfo::HTTPS_ONLY_EXEMPT_NEXT_LOAD`, the flag being set when `nsDocShellLoadState::IsExemptFromHTTPSOnlyMode` is set, when HTTPS-First is enabled, and renames both flags to reflect that behavior.
Differential Revision: https://phabricator.services.mozilla.com/D185829
- Also clear HTTPS_ONLY_EXEMPT for HTTPS-First in TestSitePermissionAndPotentiallyAddExemption
- Remove PotentiallyClearExemptFlag as we are now clearing the exemption every time
- Introduce new flag HTTPS_ONLY_EXEMPT_NEXT_LOAD which will set the exemption again after it being (potentially) cleared
- Set that flag when nsDocShellLoadState::IsExemptFromHTTPSOnlyMode is set, since that happens before the exemption is cleared
Differential Revision: https://phabricator.services.mozilla.com/D182322
To avoid unnecessary cloning of nsIInputStream, add a hasPostData
boolean attribute to tell whether a nsISHEntry has populated postData.
Differential Revision: https://phabricator.services.mozilla.com/D173237
To avoid unnecessary cloning of nsIInputStream, add a hasPostData
boolean attribute to tell whether a nsISHEntry has populated postData.
Differential Revision: https://phabricator.services.mozilla.com/D173237
With SHIP, we have a copy of the actual SessionHistoryEntry which is
responsible for a history load locally within the parent process. Using this,
we can validate any session history loads coming from the content process to
ensure that they correspond to actual outstanding history loads.
We can't do this for non-SHIP loads, as session history exists only within the
content process.
Differential Revision: https://phabricator.services.mozilla.com/D161197
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
This is largely a straightforward find and replace of various methods, with the
unnecessary arguments removed and compiler errors fixed.
Differential Revision: https://phabricator.services.mozilla.com/D148532
Previously the SessionHistoryInfo would hold onto and hand out the
original nsIInputStream objects which were provided by the
nsDocShellLoadState and used to create the underlying channel. This
could cause issues in edge cases, as input streams when serialized over
IPC have their logical owner transferred to the IPC layer so that it can
copy the data to the peer process.
This patch changes the logic to instead clone the input stream to and
from the history info. This means that the history info has its own
instance of the stream type and interacting with it shouldn't interfere
with other consumers of the post data stream.
The behaviour for non-SHIP session history is not changed, as it doesn't
serialize the relevant streams over IPC in the same way, and is on track to be
removed.
Differential Revision: https://phabricator.services.mozilla.com/D141047
Previously the SessionHistoryInfo would hold onto and hand out the
original nsIInputStream objects which were provided by the
nsDocShellLoadState and used to create the underlying channel. This
could cause issues in edge cases, as input streams when serialized over
IPC have their logical owner transferred to the IPC layer so that it can
copy the data to the peer process.
This patch changes the logic to instead clone the input stream to and
from the history info. This means that the history info has its own
instance of the stream type and interacting with it shouldn't interfere
with other consumers of the post data stream.
The behaviour for non-SHIP session history is not changed, as it doesn't
serialize the relevant streams over IPC in the same way, and is on track to be
removed.
Differential Revision: https://phabricator.services.mozilla.com/D141047
Previously the SessionHistoryInfo would hold onto and hand out the
original nsIInputStream objects which were provided by the
nsDocShellLoadState and used to create the underlying channel. This
could cause issues in edge cases, as input streams when serialized over
IPC have their logical owner transferred to the IPC layer so that it can
copy the data to the peer process.
This patch changes the logic to instead clone the input stream to and
from the history info. This means that the history info has its own
instance of the stream type and interacting with it shouldn't interfere
with other consumers of the post data stream.
The behaviour for non-SHIP session history is not changed, as it doesn't
serialize the relevant streams over IPC in the same way, and is on track to be
removed.
Differential Revision: https://phabricator.services.mozilla.com/D141047
