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
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
clang seems to have decided that a new warning,
-Wused-but-marked-unused, is useful. For the purposes of our codebase,
where we add __attribute__((unused)) explicitly to avoid warnings about
unused things, this new warning is useless. The new warning is also
quite noisy, given that we have unused things in commonly-used headers
like Assertions.h. So disable the warning.
Web animation event (i.e. finish and cancel event) is solely queued.
MozReview-Commit-ID: h1g3NfcY3c
--HG--
extra : rebase_source : 1a7b09783d193195b886fa3a046198ba3e02dd7b
That's because the target for web animation events (i.e. finish and cancel)
is an Animation instance.
MozReview-Commit-ID: 5xR325FXUo
--HG--
extra : rebase_source : 9bd0623ece1dc449d52db283882fe236dbc11c6d
Normally the refresh driver's time changes in nsRefreshDriver::Tick, and then
DocumentTimeline::WillRefresh is called for the change. But nsRefreshDriver
sometimes updates its own time when their timer changes to the active one.
This patch lets DocumentTimeline update animations in response to the refresh
driver's time updates. And thus this patch prevents animation state and
relevant stuff inconsistencies such as an animation has been finished without
proper processes, e.g. without invalidating frame for the animation.
MozReview-Commit-ID: 42p5BWITQN0
--HG--
extra : rebase_source : 58cc7d8e203a3632b6934b9d778e82e2fe208adb
mMostRecentRefresh is changed not only in Tick() but also in
EnsureTimerStarted(). In the case where it happens in Tick() refresh observers
can know it through WillRefresh(), but there is no way in the case of
EnsureTimerStarted(). This patch introduces a new abstract class to be notified
when mMostRecentRefresh was changed in EnsureTimerStarted() so that animations
can use the *real* most recent refresh time until the next tick happens.
The reason why we have another observer array in parallel with existing array
(mObservers) is that the refresh driver should stop the timer if there is no
normal observes but there are still any timer adjustment observes.
MozReview-Commit-ID: FaDcl5GrvI3
--HG--
extra : rebase_source : a6a362366f4eda9fb51003ef4cff5bea886836f0
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
