There were a couple of problems when delivering tap gestures to content with
full zoom applied. One was that the ConverToGecko function converted the coords
into "CSS pixel" space by using the web content's CSS-to-LD scale, but also
applied that on the translation from the chrome area. Moving that conversion
to later in the process (after the coords got passed through TabParent::
AdjustTapToChildWidget) corrected that issue.
The other problem was that bits of code in APZEventState and APZCCallbackHelper
were using the widget->GetDefaultScale() value as the CSS-to-LD scale, but that
omitted the full zoom value. Getting the CSS-to-LD scale from the presShell and
propagating that through corrected that issue.
MozReview-Commit-ID: KdrkdEZslHo
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.
Adds content sandbox metadata to parent and child crash reports:
Includes the value of pref security.sandbox.content.level,
whether or not the system is capable of sandboxing, if the
sandbox was successfully turned on, and (on Linux systems)
the sandbox capabilities flags.
New crash report keys:
"ContentSandboxLevel" in parent and content
"ContentSandboxCapable" in parent
"ContentSandboxEnabled" in content
"ContentSandboxCapabilities" in content on Linux
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)
In particular, this change uses the root frame of the touch target document,
so that the correct presShell resolution is used when doing the touch-action
hit test.
MozReview-Commit-ID: 2bra6PIRqkR
We're already routing the "gmp-changed" observer service notification over from
the chrome process to the content process, and it fires at pretty much the same
time as the "gmp-path-added" notification (and a few more) so we can just switch
to have the MediaKeySystemAccessManager listen on that notification instead, and
we'll be e10s compatible.
MozReview-Commit-ID: EowFDfdWgAJ
--HG--
extra : rebase_source : ad01990278cf9005f6676ef0b7fa0acbf69249eb
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)
Callers should use a UniquePtr to hold the platform handle.
MozReview-Commit-ID: 6BWnyAf4b3a
--HG--
extra : transplant_source : %26%CA%0D%28%08%9BT%97Z%A1%3Dq%CD%21%A1_%EFE%83%0E
extra : histedit_source : 77f8ed3d0fdec6cce0c95469130ade0fb547bb91
By the time that the parent is being asked to create a new window, the name
really doesn't matter anymore.
MozReview-Commit-ID: 4IKrEEylaLY
--HG--
extra : rebase_source : bcb7e316534c522a5ff8d7be336c940eccffbe3e
extra : source : e91913cd64b8bebe80c661935adee644f24c6055
This removes the unnecessary setting of c-basic-offset from all
python-mode files.
This was automatically generated using
perl -pi -e 's/; *c-basic-offset: *[0-9]+//'
... on the affected files.
The bulk of these files are moz.build files but there a few others as
well.
MozReview-Commit-ID: 2pPf3DEiZqx
--HG--
extra : rebase_source : 0a7dcac80b924174a2c429b093791148ea6ac204
