This commit adds the CONTENT_FRAME_TIME metric which tracks the time from the beginning
of a paint in the content process until it is presented in the compositor.
There is existing logging for frame latency which tracks from the beginning of a refresh
tick until the frame is presented. This is undesirable for this probe as javascript and
layout can run in this time period. So this probe uses the existing infrastructure for
logging frame latency, but uses a start time from BeginTransaction in layer manager.
MozReview-Commit-ID: 5z9LS3tsZTY
This commit adds the CONTENT_FRAME_TIME metric which tracks the time from the beginning
of a paint in the content process until it is presented in the compositor.
There is existing logging for frame latency which tracks from the beginning of a refresh
tick until the frame is presented. This is undesirable for this probe as javascript and
layout can run in this time period. So this probe uses the existing infrastructure for
logging frame latency, but uses a start time from BeginTransaction in layer manager.
MozReview-Commit-ID: 5z9LS3tsZTY
A hidden preference matching "browser.download.manager.alertOnEXEOpen" is kept, but is renamed in order to recover cases where the checkbox was used accidentally.
This also cleans up duplicate unused strings in the "browser" folder.
MozReview-Commit-ID: GyccRiyoVGs
The general setup is that the State struct is used to iterate over text nodes
explicitly, and keeps references to the ranges so that we don't need to pass all
them around everywhere.
We need to teach nsFindContentIterator to rewind into NAC to be able to get rid
of mIterNode, which was getting out of sync when we failed to rewind to the
anchor node.
MozReview-Commit-ID: 5czYADrm1WX
While ParseError was used throughout the codebase, errors were detected
but not reported due to the missing |atexit| handler. This also makes
string checking only run when strict checks are enabled.
Differential Revision: https://phabricator.services.mozilla.com/D1910
Previously accessing the "canUpload" attribute in user code was not
possible, as it was blocked due to security constraints.
By explicitely copying it, the object is accessible in user code and
HybridContentTelemetry correctly reads the attribute.
Unfortunately the tests in
tests/browser/browser_HybridContentTelemetry.js don't have this issue,
as apparently their content process runs with higher privileges.
This change was tested locally to work as expected.
MozReview-Commit-ID: HbNH4wEyOA
Differential Revision: https://phabricator.services.mozilla.com/D1879
This patch adds three telemetry scalars to track how WebP is used. All
of these scalars are updated when we do the MIME type confirmation for
an imgRequest when the first data comes in. We know at this point we
decided to load the given content, so there should be minimal false
positives for data the browser loaded but never displayed.
The first two scalars are merely whether or not WebP was observed. One
is for probes, which are tiny WebP images suggested by the Google WebP
FAQ to probe for different aspects of WebP support (lossy, animated,
etc). We want to count this separately as actual WebP content that the
website wishes us to display. Probes will give a measure of how many
users visit websites that probe for WebP support, and content will give
a measure of how many websites don't care and just give us WebP images
regardless.
The third scalar is intended to give a relative measure of how many WebP
images we are being served relative to all other image types. We expect
the ratio to be small, but it would be good to confirm this from the
data.
