Make nsISHistory support partial mode and create interfaces which
DOM level grouped session history should implement.
MozReview-Commit-ID: BXhBY6aJ0f7
--HG--
extra : rebase_source : bee5fd8354d2fdef8b3bac202d158c95c7e4e6e0
Renamed CompareFrames to LoadDifferingEntries to make what it does more clear.
Also, use this to do the top level load for the forward / back cases as it is pretty much set up to do that already.
MozReview-Commit-ID: G8cO0jDZebR
--HG--
extra : rebase_source : 4c9f3d77ad29ad5c447efd7c702b37c5581de1ab
This function was mistakenly returning mPrivateBrowsingId instead of
mInheritPrivateBrowsingId. Thankfully this function isn't being used
anywhere yet.
|refreshURIList| is converted to a an nsIMutableArray as nsISupportsArray is
deprecated. This attribute is only used internally and does not show up in a
textual search of the plugins repo.
nsIMutableArray is used rather than nsIArray in order to support modifying the
array as current users expect.
MozReview-Commit-ID: F0GYVFZarOQ
For toplevel document loads (TYPE_DOCUMENT) in the content process,
we pass the currently-loaded window, if any.
For toplevel document loads in the chrome process (e.g. tabs in non-e10s mode),
we pass the node which created our docshell, if any.
For all subframe loads, we pass the node that created the docshell,
which is the frameElement of the window in the docshell.
In Bug 841850 we added a !isNewDocShell check.
And In Bug 902350 we added a !isTargetTopLevelDocShell check.
We can get rid of isNewDocShell variable and just keep track of
isTargetTopLevelDocShell.
In nsIContentPolicy terminology, it uses 'requestingPrincipal'.
So in nsDocShell::InternalLoad, we rename 'loadingPrincipal' to
'requestingPrincipal', and rename 'context' to 'requestingContext' when
calling nsIContentPolicy.
This seems like much the simplest way to prevent the recursion. Other alternatives
include some kind of member var to track state (which wouldn't be threadsafe, though
I don't know that that really matters for this component) or adding a field on
nsIDefaultURIFixupInfo, which seems ugly. This is a bit hacky, but it seems to work.
MozReview-Commit-ID: 7CCVvENSRVD
--HG--
extra : rebase_source : b42552de2607ba4830757adcd6be6df2b27c76ee
HSTS priming changes the order of mixed-content blocking and HSTS
upgrades, and adds a priming request to check if a mixed-content load is
accesible over HTTPS and the server supports upgrading via the
Strict-Transport-Security header.
Every call site that uses AsyncOpen2 passes through the mixed-content
blocker, and has a LoadInfo. If the mixed-content blocker marks the load as
needing HSTS priming, nsHttpChannel will build and send an HSTS priming
request on the same URI with the scheme upgraded to HTTPS. If the server
allows the upgrade, then channel performs an internal redirect to the HTTPS URI,
otherwise use the result of mixed-content blocker to allow or block the
load.
nsISiteSecurityService adds an optional boolean out parameter to
determine if the HSTS state is already cached for negative assertions.
If the host has been probed within the previous 24 hours, no HSTS
priming check will be sent.
MozReview-Commit-ID: ES1JruCtDdX
--HG--
extra : rebase_source : 2ac6c93c49f2862fc0b9e595eb0598cd1ea4bedf