Summary:
We can't create a H264 VT decoder until we have all SPS/PPS NALs, which makes it tricky to generate when we only want to check if H264 is supported.
On mac, we can reasonable assume that hardware acceleration is always supported (though on a mac pro 2013 that isn't the case or hackintosh with nvidia cards).
Depends on D1625
Tags: #secure-revision
Bug #: 1409664
Differential Revision: https://phabricator.services.mozilla.com/D1626
Summary:
We know those sampling rate aren't supported and cause initialization errors later.
Depends on D1624
Tags: #secure-revision
Bug #: 1409664
Differential Revision: https://phabricator.services.mozilla.com/D1625
Summary:
Allows to build an array ot TrackInfo built from the mimetype provided. This will allow to create dummy decoder to check that if they are supported and how well the decoder will perform.
Depends on D1623
Tags: #secure-revision
Bug #: 1409664
Differential Revision: https://phabricator.services.mozilla.com/D1624
Summary:
Addtionally, change the framerate to be of type double and allow to create a MediaExtendedMIMEType based on the new dom VideoConfiguration and AudioConfiguration object.
Depends on D1622
Tags: #secure-revision
Bug #: 1409664
Differential Revision: https://phabricator.services.mozilla.com/D1623
Summary:
TaskQueue no longer requires an explicit call to BeginShutdown() as such we no longer have a need for AutoTaskQueue.
Depends on D1621
Tags: #secure-revision
Bug #: 1409664
Differential Revision: https://phabricator.services.mozilla.com/D1622
Summary:
With this change TaskQueue no longer requires an explicit call to BeginShutdown(). The taskqueue will automatically shutdown once it's now longer referenced.
Depends on D1620
Tags: #secure-revision
Bug #: 1409664
Differential Revision: https://phabricator.services.mozilla.com/D1621
Summary:
The information returned is identical to
1- canPlayType() for file
2- MediaSource.isTypeSupported for media-source
3- MediaRecorder.isTypeRecorder() for recordings.
Depends on D1616
Tags: #secure-revision
Bug #: 1409664
Differential Revision: https://phabricator.services.mozilla.com/D1617
If GetInitialInterceptorForIID fails, the live set lock is not released in most cases, but the newly created Interceptor will be destroyed.
The Interceptor's destructor tries to acquire the live set lock again, but that causes a deadlock, since reentry is no longer allowed for a mutex after bug 1364624.
GetInitialInterceptorForIID now ensures the live set lock is always released on failure, thus preventing the deadlock.
MozReview-Commit-ID: z0Q7JLnJXQ
--HG--
extra : amend_source : 0b9837e5500754b5782e72337fc59b7904c5e29c
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
Jean-Yves Avenard
Olli Pettay
Jason Laster
James Teh
Noemi Erli
James Willcox
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