Instead, MediaDecoder::NextFrameStatus() checks IsEnded() and returns
NEXT_FRAME_UNAVAILABLE to ensure we have HAVE_CURRENT_DATA when playback
is ended on the main thread.
This will fix the timing issue (comment 0) which causes 'waiting' to fire.
MozReview-Commit-ID: 7O21x2q0lb8
--HG--
extra : rebase_source : 0a676ef7278214a707c97687311a73da8bcd983e
extra : intermediate-source : 2b3e413db02a7aad00d13fdf274b346bccafc414
extra : source : 6f60fad11b65e75b456e128f8414fe2ea545455f
This is a temporary step until we implement bug 1391537. It is needed to
maintain consistent behavior with Gecko and provide sensible output,
particularly in the case where we have longhands whose values are drawn from
unparsed shorthands.
MozReview-Commit-ID: 9aD2tsLagBp
--HG--
extra : rebase_source : cdabb26be17b96a574ea8b2e8093e11abb1af430
This test passes both before and after the code changes in the following patch
in this series. However, both tests fail if we try to expand variables in
Servo_StyleSet_GetKeyframesForName.
MozReview-Commit-ID: LHOsK39WDLq
--HG--
extra : rebase_source : 225cfccbf439c35df943d0aed969825051354dec
These are the Servo-side changes for [Gecko bug 1385139](https://bugzilla.mozilla.org/show_bug.cgi?id=1385139).
This is a temporary step needed to support Gecko's getKeyframes() API until we implement bug 1391537. It only takes effect when a ComputedValues object is supplied and only for longhand declarations.
Source-Repo: https://github.com/servo/servo
Source-Revision: 9bb21e6cab637380a544f941ab742dd47b8133b4
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : e7d62370a1e13c014bb0b9dac1d0fbea360b56e6
The IMFTransform interface used by MFTDecoder is documented to require to run
on an MTA threads:
https://msdn.microsoft.com/en-us/library/windows/desktop/ee892371(v=vs.85).aspx#components
We're currently using IMFTransform objects on the main thread, which is STA.
So delegate calls to the IMFTransform to the MTA thread when necessary, to
ensure it always runs on an MTA thread.
The existing uses of IMFTransform objects in the decode thread pool threads
will be fine, as those threads are already MTA.
We also defer initialization of WMF to the MTA thread, so that we're always
interacting with WMF on an MTA thread.
MozReview-Commit-ID: Dm8XpdvJLkS
--HG--
extra : rebase_source : 0807241c8cdd01c1b99bf946ea4728996ac61f68
It isn't possible for the End of Stream algorithm to cause an updateend event to fire. Regardless of the duration being modified.
MozReview-Commit-ID: 5RppbtjkboN
--HG--
extra : rebase_source : 6d30be7758bda59c545324358c82c47e6b0c73b1
In bug 1312886, we made sure that readyState would never become HAVE_ENOUGH_DATA if we were waiting for a key.
However, this is in effect useless as the next call to ChangeReadyState would have reset mWaitingForKey.
In practice, it only meant that we delayed the change from HAVE_FUTURE_DATA to HAVE_ENOUGH_DATA until the next call to UpdateReadyState.
MozReview-Commit-ID: 2wnMeN8xxCS
--HG--
extra : rebase_source : f5b0fa50ead1565882c3bf8ba245702987784d8a
By default, a media element that has never played is in paused mode. As such, we need to reset mWaitingForKey to NOT_WAITING_FOR_KEY otherwise, readyState will never become HAVE_ENOUGH_DATA.
MozReview-Commit-ID: EIi3Crt4zHl
--HG--
extra : rebase_source : e9f9ad4136020db7db081b5c125f664e1c7bda20
We load 10s of encrypted video, which should trigger readyState being HAVE_ENOUGH_DATA
MozReview-Commit-ID: 4VRLFHSFlDs
--HG--
extra : rebase_source : 919310b00f0ec271a73e149992696bc1eec8cd5f
GTK is definitely not thread-safe, and unless proven otherwise, I suspect the
other widgets aren't either.
Mutex the calls to get the system color stuff.
There are chances to make this more fine-grained moving the mutexes into the
specific widget code and when needed. That is more analysis work which I'm not
sure we should waste time on, since the chances on racing here seem quite
unlikely in practice (system colors are uncommon enough in content, I guess).
MozReview-Commit-ID: AOQQ2jtkgpx