There was a cycle amoung a window object -> a HTMLMediaElement -> a MediaDecoder -> a Promise (-> back to the window object).
And we have no way to break the cycle since the MediaDecoder does not participate into the collection.
By moving the Promise form MediaDecoder to HTMLMediaElement, we will be able to break the cycle since the HTMLMediaElement is in the collection.
We'll implement the cycle collection in the next patch.
MozReview-Commit-ID: CyVXBl6IMI3
--HG--
extra : rebase_source : 195a322ce3e6fe933e72be4aec5d2ebfa1f54865
On Fennec, we use external video player to play unsupported type media.
In this bug, we can't execute play() successfully because the spec said that
we should abort the play if the value of media element's error is
MEDIA_ERR_SRC_NOT_SUPPORTED [1].
Therefore, we do a hack for unsupported type media, we don't set its error, but
we would still remember the src is unsupported type. When media element starts
playing, we would use an external video player to play that src.
[1] https://goo.gl/GlLbeA
MozReview-Commit-ID: 42HxQtXdWDe
--HG--
extra : rebase_source : 83425528eacee8af1829eaead2fef39b0be51ae5
Since the audible state would depend on pause and suspend state, we should do
the check after finishing play() or pause().
MozReview-Commit-ID: 1yhxuQDw067
--HG--
extra : rebase_source : 888bac3da52f42b75eeb1c3db1337e223d792a11
If the media element is paused, it should be non-audible.
MozReview-Commit-ID: 2HjV9gNNcnV
--HG--
extra : rebase_source : 39b0812788d020d3f9c1a96afa1397b32057de8c
Since the window would know when need to resume the media, we don't need the
add/removeMediaContent() anymore.
MozReview-Commit-ID: F9MSiqqnOiV
--HG--
extra : rebase_source : fa86b3977e13d1f2a6b6233b6d608ccc331b5bf7
Since the window would know when need to resume the media, we don't need the
add/removeMediaContent() anymore.
MozReview-Commit-ID: F9MSiqqnOiV
--HG--
extra : rebase_source : 28a8312373054b8e29b93267677de99dd862a074
This mMediaTracksConstructed flag should belong to a MediaDecoder,
every time a HTMLMediaElement switches its MediaDecoder, the flag should be reset to false again.
So, we move the mMediaTracksConstructed flag back to MediaDecoder, by this way,
HTMLMediaElement provides only the mechanism to construct and remove media tracks,
and MediaDecoder uses the flag, mMediaTracksConstructed, to provide policy.
MozReview-Commit-ID: L7mMAmLjQCy
--HG--
extra : rebase_source : 1625d604afb34bffe79eda06a46c9feb780a14d9
We should remove the media control interface immediately when the document is inacitve, even it was paused by media control before.
MozReview-Commit-ID: GBDhzEFOTXE
--HG--
extra : rebase_source : f357d19ceb26d307d1d68696ad875d044e14aa8b
Move the creation of MediaElementGMPCrashHelper out from MediaDecoder.cpp
which reduces the dependency of MediaDecoder to HTMLMediaElement.
MozReview-Commit-ID: E60aMfcFr7V
--HG--
extra : rebase_source : f50a8ee6f2fbec0bdf117eb1217066bc9c701745
extra : source : dd4e52da6d0d6205fe61d0caba44bbff008fd21a
ConstructMediaTracks and RemoveMediaTracks are actually HTMLMediaElement's responsibilities.
MozReview-Commit-ID: 8lOdzD4pN7N
--HG--
extra : rebase_source : 7159d2c62b77429e5b2305b9e3eb7a0020a3b52c
extra : source : 0467c059be3cd8f066da5fc912b7738a5b9c4dd9
Open a GetOwnerDoc() method to the MediaDecoderOwner interface and then we can get the
owner document via a pointer to MediaDecoderOwner in MediaDecoder.
MozReview-Commit-ID: JCzQDLx1MsU
--HG--
extra : rebase_source : e194c95cb1513046ec7aa19d6c6e9f8231971a2d
extra : source : 1b9c45911a036e3677b6636cda84a636681d71de
We never suspend videos that is NOT in-tree because we found that, according to the Telemetry data, most (>70%) videos
which are used as the argument of drawImage() are not in-tree. So, by preventing suspending not-in-tree videos, we should
be able to alleviate the pain of not able to resume video decoders synchronously.
MozReview-Commit-ID: 8eqs0pHZLIt
--HG--
extra : rebase_source : 964c0047753696cad2e40bcf74c2b8ee9faccdea
extra : source : 93c38caa15b1a29f8f1e8e6d3a5e859f97bc1aae
Initialize the MediaDecoder::mIsElementVisible to be "!aOwner->IsHidden()" at the MediaDecoder's constructor is wrong.
Insted, we initialize both MediaDecoder::mIsDocumentVisible and MediaDecoder::mIsElementVisible to be false at the construtor,
and then assign the HTMLMediaElement's real values to them at HTMLMediaElement::FinishDecoderSetup() via the the MediaDecoder::SetActiviyChangesToDecoder().
The initialization values of MediaDecoder::mIsDocumentVisible and MediaDecoder::mIsElementVisible (in the constructor) do not matter because the valuse are
not read untile the first MediaDecoder::SetActiviyChangesToDecoder() method call.
MozReview-Commit-ID: Cdovq5pG9Nv
--HG--
extra : rebase_source : 91f3b4c2515124b4c195dd246bd9b404178a35de
extra : source : 81b5e89a5bd20f37b8c3daa1230db30808026ff4
Make HTMLMediaElement no longer has logic of deciding visibility, it just passes all information into MediaDecoder.
MozReview-Commit-ID: ApVcEQfboO
--HG--
extra : rebase_source : 88c70b0cf1933d9cf814359909463a811be2ab9f
extra : source : 669d1340d3c93d3e0eab55ce87693f842cf40247
Move all the policy rules into this method now, will then move the policies into MediaDecoder at next patch.
MozReview-Commit-ID: ILAYLrTwCJy
--HG--
extra : rebase_source : 8ae3adcbbd8f2fd61f0da0de437f41f78d945c89
extra : source : feb8ad754e86b43e15bf2eeb3a2ba2dc24a00599
MDSM's dormant mechanism has nothing to do with the HTMLMediaElement's states now.
MozReview-Commit-ID: 4RSHsexy7fi
--HG--
extra : rebase_source : cb84fda2c182c63c6276b143ce071afc01c694d8
extra : source : af0217686959affe143167487588faab137212ce
Mark video element as tainted (stored on the decoder owned by video element) when the video is used as source to drawImage() on canvas.
MozReview-Commit-ID: HdciVwhqPu3
--HG--
extra : rebase_source : 79e1bbdc671abb8555d68f7fb6106929c45fd528
extra : intermediate-source : 47fbcedbed69a5434b1cb25b8f72f862e9cefeac
extra : source : 149234329b62015dfd2e954030c23bf9c6b1d55e
Mark video element as tainted (stored on the decoder owned by video element) when the video is used as source to drawImage() on canvas.
MozReview-Commit-ID: HdciVwhqPu3
--HG--
extra : rebase_source : b26c257afaaabdd6346a5421988d95e82281d7ef
extra : source : 149234329b62015dfd2e954030c23bf9c6b1d55e
If the media starts after muting the tab, IsOwnerAudible() would always return
"eNotAudible". It causes that the "play tab" icon can't be displayed because we
only show the "play tab" icon for the "eMaybeAudible" or "eAudible".
We should check whether owner owns the audio track to decide the return value.
MozReview-Commit-ID: DGwkArx0a4R
--HG--
extra : rebase_source : 920968acc744593f4ef383be4068352233c74101
In bug1319771, we found that the tab would become visible unexpectly in short
period in some situations. We don't want to resume the tab in this kind of
situation, so we check whether there is any alive media component in the tab
using IsServiceStarted(). However, since we have lots different ways to create
the service, this function is not accurate at all.
Therefore, we can add media element directly to the document when it binds to
tree so that we can really know whether there is any alive media component.
MozReview-Commit-ID: FvZFg91IqgE
--HG--
extra : rebase_source : 43c2460f6e9a39d44bf2ca1638c992a0e27b196c
Similar to DecodeError, except we allow decoding to continue.
MozReview-Commit-ID: FN9m03o6GXV
--HG--
extra : rebase_source : a6ca0cc28d2990ab143676758cd880baaca7bcb7
