This will allow us to determine which app is crashing for
crashes that come from GeckoView. I've also renamed the
AndroidProcessName field to Android_ProcessName for consistency.
MozReview-Commit-ID: JL1u7VVxbSx
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
This patch adds a sanitization of firstPartyDomain when calling the
OriginAttributes::CreateSuffix() and remove the release assert there.
The cookies API for the web extension can use a arbitrary string for the
firstPartyDomain. So, we should sanitize the firstPartyDomain before
we creating a suffix. The release assert is not required anymore since
the firstPartyDomain is sanitized
Depends on D1845.
Differential Revision: https://phabricator.services.mozilla.com/D1856
--HG--
extra : moz-landing-system : lando
Added method 'trackAttached' to the class 'GetIteratorIRGenerator' and implemented it accordingly.
MozReview-Commit-ID: CRLXFaOfgZD
--HG--
extra : rebase_source : 8c0554ef2a820b2efb1e89b1d847b127204ad5a7
Added sanity check to check if the send rid in simulcast is defined by any send rid.
MozReview-Commit-ID: GISzaQqdqBI
--HG--
extra : rebase_source : 32416045cdb8c96dff72ee74d1d84121323d358f
ToolboxTabs can leave some listeners still bound after unmount leading to errors
during test runs.
Differential Revision: https://phabricator.services.mozilla.com/D1892
--HG--
extra : moz-landing-system : lando
Noemi Erli
James Willcox
Olli Pettay
Gijs Kruitbosch
Jeff Gilbert
Daisuke Akatsuka
Matt Woodrow
Brindusan Cristian
Bobby Holley
Dustin J. Mitchell
shindli
Gregory Szorc
Chris Pearce
Tim Huang
Morgan Rae Reschenberg
Petru Gurita
Jonathan Kingston
Chris AtLee
Johannes Willbold
Karl Dubost
J. Ryan Stinnett
Michael Kaply
Dragan Mladjenovic
Geoff Brown
Andrew Osmond