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
Telemetry probe, for feedback (using r? in mozreview) by telemetry peer.
This probe records a what-if scenario where video decoding would be suspended,
so we can guage the actual benefits we would gain.
MozReview-Commit-ID: 5caNjEVl1ti
--HG--
extra : rebase_source : 274b11f935ec53ce31d8b6cf9b256f11cb9ba702
Telemetry probe, for feedback (using r? in mozreview) by telemetry peer.
This probe records a what-if scenario where video decoding would be suspended,
so we can guage the actual benefits we would gain.
MozReview-Commit-ID: 5caNjEVl1ti
--HG--
extra : rebase_source : 274b11f935ec53ce31d8b6cf9b256f11cb9ba702
r?francois for telemetry-peer feedback through mozreview.
The goal of this telemetry is to gather statistics about inter-keyframe timings
of played videos, so we have a better understanding of typical values in the
field.
This inter-keyframe time is important for the background-suspend functionality,
as it will impact the recovery time (i.e., when moving a video back to the
foreground, what is the average & max time to the next random-access point?)
MozReview-Commit-ID: NISIf1wGtU
--HG--
extra : rebase_source : 34eb0bc852d4ae05701c56e38b3b0dc9c75d708e
The telemetry results indicate there's not a big problem here that we need to
solve. So doesn't seem worth while keeping the probes.
MozReview-Commit-ID: Jnh2Od6jV2X
--HG--
extra : rebase_source : e68addd5883b56c20caaad4c4e958221069f9692
We're actively trying to encourage people to install Windows system decoders to
drive the "can't create" number to 0. So we need this probe to measure our
progress.
MozReview-Commit-ID: BDE7nbaK4NX
--HG--
extra : rebase_source : d98da189ad94906ff79085aac7e0d4bed9e018ce
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)
The WebRTC implementation inherits cipher suite preferences from PSM and then
enables a few mandatory ones and disables a number of undesirable ones. If PSM
makes a change to a cipher suite preference that isn't in WebRTC's whitelist or
blacklist, compatibility issues can arise. See bug 1288246 for an example.
--HG--
rename : security/manager/ssl/tests/unit/test_fallback_cipher.js => security/manager/ssl/tests/unit/test_weak_crypto.js
