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
Provides access to the browser's internal Find APIs. Can search,
get range data and rect data on found results, and highlight results.
MozReview-Commit-ID: 6hbNJuvJO3
