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.
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
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
The new name makes the sense of the condition much clearer. E.g. compare:
NS_WARN_IF_FALSE(!rv.Failed());
with:
NS_WARNING_ASSERTION(!rv.Failed());
The new name also makes it clearer that it only has effect in debug builds,
because that's standard for assertions.
--HG--
extra : rebase_source : 886e57a9e433e0cb6ed635cc075b34b7ebf81853
This function is an infallible alternative to nsIURI::GetSpec(). It's useful
when it's appropriate to handle a GetSpec() failure with a failure string, e.g.
for log/warning/error messages. It allows code like this:
nsAutoCString spec;
uri->GetSpec(spec);
printf("uri: %s", spec.get());
to be changed to this:
printf("uri: %s", uri->GetSpecOrDefault().get());
This introduces a slight behavioural change. Previously, if GetSpec() failed,
an empty string would be used here. Now, "[nsIURI::GetSpec failed]" will be
produced instead. In most cases this failure string will make for a clearer
log/warning/error message than the empty string.
* * *
Bug 1297961 (part 1b) - More GetSpecOrDefault() additions. r=hurley.
I will fold this into part 1 before landing.
--HG--
extra : rebase_source : ddc19a5624354ac098be019ca13cc24b99b80ddc
- added overrideDPPX to nsIContentViewer
- made CSSStyleSheet and GlobalWindow using the overrideDPPX value
- added unit test with frame check
MozReview-Commit-ID: AOWpGs4vb9H
--HG--
extra : rebase_source : 45d9ae2c9b7aad835b5602e805ec7260c69c05b8
The patch is generated from following command:
rgrep -l unused.h|xargs sed -i -e s,mozilla/unused.h,mozilla/Unused.h,
MozReview-Commit-ID: AtLcWApZfES
--HG--
rename : mfbt/unused.h => mfbt/Unused.h
This patch makes GetBounds(), GetScreenBounds() and GetClientBounds() more
obviously infallible, like existing functions such as GetNaturalBounds() and
GetClientSize(). This results in clearer behaviour in nsCocoaWindow.mm if
Objective C exceptions occur. Along the way, the patch removes some useless
failure checks for these functions.
The patch also removes the NS_IMETHOD from GetRestoredBounds and makes that
function MOZ_MUST_USE.
This makes a lot of code more compact, and also avoids some redundant nsresult
checks.
The patch also removes a handful of redundant checks on infallible setters.
--HG--
extra : rebase_source : f82426e7584d0d5cddf7c2524356f0f318fbea7d
Make sure the mPrivateBrowsingId of Origin Attributes is consistent
between LoadInfo and LoadContext.
For chrome docshell, its mPrivateBrowsingId remains 0 even if its
UserPrivateBrowsing() is true (bug 1278664). So we sync the
mPrivateBrowsingId field in LoadInfo in the same way.
Slightly less than half (93 / 210) of the NS_METHOD instances in the codebase
are because of the use of NS_CALLBACK in
nsI{Input,Output,UnicharInput},Stream.idl. The use of __stdcall on Win32 isn't
important for these callbacks because they are only used as arguments to
[noscript] methods.
This patch converts them to vanilla |nsresult| functions. It increases the size
of xul.dll by about ~600 bytes, which is about 0.001%.
--HG--
extra : rebase_source : c15d85298e0975fd030cd8f8f8e54501f453959b
This patch makes the following changes on many in-class methods.
- NS_IMETHODIMP F() override; --> NS_IMETHOD F() override;
- NS_IMETHODIMP F() override {...} --> NS_IMETHOD F() override {...}
- NS_IMETHODIMP F() final; --> NS_IMETHOD F() final;
- NS_IMETHODIMP F() final {...} --> NS_IMETHOD F() final {...}
Using NS_IMETHOD is the preferred way of marking in-class virtual methods.
Although these transformations add an explicit |virtual|, they are safe --
there's an implicit |virtual| anyway because |override| and |final| only work
with virtual methods.
--HG--
extra : rebase_source : 386ee4e4ea2ecd8d5001efabc3ac87b4d6c0659f
This patch makes most Run() declarations in subclasses of nsIRunnable have the
same form: |NS_IMETHOD Run() override|.
As a result of these changes, I had to add |override| to a couple of other
functions to satisfy clang's -Winconsistent-missing-override warning.
--HG--
extra : rebase_source : 815d0018b0b13329bb5698c410f500dddcc3ee12
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.
(r=ckerschb,r=mayhemer,r=jld,r=smaug,r=dkeeler,r=jmaher,p=ally)
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.