This adds a probe called TIME_TO_NON_BLANK_PAINT_MS which reports time to
non-blank paint for root content documents whose docshell was active for the
entire time between navigation start and first non-blank paint.
MozReview-Commit-ID: 7JQdk5vHr1O
This allows us to track how often EME CDMs are used, rather than just created.
The telemetry I added in bug 1304207 is reports whenever a CDM is created, but
some sites, such as the Shaka Player demo site, create CDMs without using them,
so that telemetry isn't a great measure in helping us detect when CDMs aren't
being used. Whereas the telemetry added here will report when the CDMs are used
to negotiate a license, i.e. when the CDMs are actually being used.
MozReview-Commit-ID: ExMIcIIBvS1
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
This allows us to track how often EME CDMs are used, rather than just created.
The telemetry I added in bug 1304207 is reports whenever a CDM is created, but
some sites, such as the Shaka Player demo site, create CDMs without using them,
so that telemetry isn't a great measure in helping us detect when CDMs aren't
being used. Whereas the telemetry added here will report when the CDMs are used
to negotiate a license, i.e. when the CDMs are actually being used.
MozReview-Commit-ID: ExMIcIIBvS1
We've now seen an OOM trying to grow the accumulations array during a test
suite. The g*Accumulations arrays do grow unboundedly in size waiting for the
IPC timer to fire, so we should put a size bound as well as a time bound to
trigger the batch send.
The current size bound is 5K elements. This was chosen out of a hat.
MozReview-Commit-ID: 5HeWdbLfN03
We're seeing occasional failures of the isValid assert on the parent side where
the ID we're being asked to accumulate on is invalid.
Check the IDs on both sides to ensure that they're valid heading in.
MozReview-Commit-ID: 4gLG54Tx64s
nsTimer fires on the thread that created the timer. An nsTimer instance should
only be manipulated on its target thread (it isn't threadsafe). IPC using
PContent must be on the main thread.
Thus, everything to do with the gIPCTimer must be on the main thread.
This also takes care of bug 1299312.
MozReview-Commit-ID: IcVRYsoX2R9
Rewrite the categorical histogram accumulation code to use the common path.
This way it gets remote accumulation for cheap.
MozReview-Commit-ID: 3q6gdSvBix
I saw a one-off crash on try in internal_GetHistogramByEnumId. Not reproducible
but maybe possible if we're trying to accumulate using an invalid ID. So let's
guard against that.
MozReview-Commit-ID: Ei6eTlV91mJ
On content process shutdown we send a content process ping to ensure we have
up-to-date data from the content process before it goes away. Now we need to
also flush the batched telemetry accumulations to the parent so that it can be
present in the ping.
No attempt is made to synchronize access to IPCTimerFired. It is safe to
re-enter.
No attempt is made to cancel the timer as its firing is benign.
MozReview-Commit-ID: 1gjNH9IPhKf
Clear isn't generally called at all, and isn't dispatched to the parent process
for child telemetry aggregation. Clear should only be called on the parent
process.
MozReview-Commit-ID: stIutvAO6h
The JS histograms, too, need to dispatch their accumulations from child to
parent.
JSHistograms_Add now only supports histograms that are in gHistogramsMap or
that were created in the parent process. After bug 1288745, maybe we'll be able
to change this to be less convoluted.
MozReview-Commit-ID: 3qTH89YKbGP
Take the opportunity presented through changing child telemetry accumulation
to bring the ping form closer to the ideas expressed in bug 1281795.
childPayloads still exists, but without histograms or keyedHistograms which are
now at root.processes.content.{keyedH|h}istograms. This will require coordinated
changes in the aggregator and moztelemetry libraries.
MozReview-Commit-ID: AqG2jmBBC2W
To simplify using child telemetry from the parent process, only allow child
telemetry payloads to be generated once per child process, on shut down.
This will allow us to use the child telemetry's subsession information to leave
childPayloads the way it currently is.
Will need to update test_ChildHistograms.js as it is the only consumer.
MozReview-Commit-ID: 2qSztg0QHV5
I originally thought we'd be able to avoid the previous implementation's waste
of a map full of every kind of keyed histogram. Unfortunately, other code
(TelemetrySession at the very least) depends on this (and will throw if a keyed
histogram isn't present, even if it is empty)
MozReview-Commit-ID: 8MCGVa595UB
The original commit didn't properly support subsession histograms, so rectify
that lapse by adding support for stripping out the base name of a histogram
when trying to determine its id.
MozReview-Commit-ID: LvUek6f5WUx
Batch the accumulations to only transmit every so often, so we don't incur
too much in the way of IPC overhead penalties.
What this doesn't do:
* remove or restructure child telemetry code to adapt to the new way
* send the telemetry anywhere
* allow for the child process to clear child histograms
* support anything but histograms (but this is expected and okay)
MozReview-Commit-ID: JnUkcmN3Ya7
Add opt-out telemetry probe to track which EME CDMs are being instantiated.
This will enable us to determine when it's safe to remove the Adobe CDM.
MozReview-Commit-ID: iEPSTk7UtP
