This makes one less place where we link code compiled for libxul into a
place that doesn't link mozglue, and is cleaner to boot. We don't need
the BREAKPAD_NO_TERMINATE_THREAD define that breakpad-windows-libxul
defines because we're not including the handler code in the
crashreporter binary.
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
--HG--
extra : rebase_source : cecb7149f50b2abe7a827dc20f1e8b8ade199258
extra : histedit_source : 581f8f38fc8335575d7275b903a8e1d6a9e5a369
The intent is for the build system to soon require Node.js to build
Firefox. But we aren't ready to make Node.js a build requirement
just yet.
The goal of this commit is to implement configure detection for
Node.js so that we can a) work out detection bugs b) give people a
means to validate system compatibility *before* we throw the switch to
require Node.js.
This commit introduces configure logic for finding a Node.js
executable, resolving its version, and validating its suitability.
By default, if Node.js cannot be found or there is an error resolving
its version, we print some warning messages and move on.
If --enable-nodejs is used (not the default), errors are raised
if Node.js cannot be found or its version isn't suitable.
Once we require Node.js, the added code can likely be simplified.
When writing the code, I went out of my way to make failures as
non-fatal as possible. e.g. normally we'd say that failures to run
`node --version` would be fatal. I'm purposefully trying to not have
this configure check break anyone's environment, even if failure
occurs. Again, the goal is to introduce the configure checks first
in a non-fatal way such that we can debug failures so the flag day
transition is simpler.
Differential Revision: https://phabricator.services.mozilla.com/D1818
--HG--
extra : moz-landing-system : lando
(This patch was first presented for review in bug 1463919, I've split it off
into its own bug here).
If the user opens a tab in the background, and that tab tries to play media,
we'll delay playing that media until the tab is brought to the foreground.
But the user can explicitly start playback of such delayed media by clicking
the "play" icon we show in the tab indicator. Then if autoplay is disabled,
we'll block the play (unless the origin is whitelisted). This is bad, as the
user has clearly indicated intent to play media in this tab.
So this patch "gesture activates" the root content document when the tab audio
indicator play button is pressed. This means the block autoplay logic will
behave as if there's been a user gesture in the tab (mouse click or keypress),
and not block the play. Gesture activation state is per document, so it does
not persist across document loads.
MozReview-Commit-ID: 3pgrADRrJqt
***
fix
--HG--
extra : rebase_source : 3290571b61cfed5653cd75c859c8520ef5c8ee2f
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
--HG--
extra : rebase_source : 8211ad1c94894535b2b98dde0549d7ab52a879b0
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
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.