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
If we don't have any alive track in MediaTrackList, we don't need to mute
MediaElement.
MozReview-Commit-ID: 9vY692O7N0e
--HG--
extra : rebase_source : 3abd2fb360385b1975dbffd9dcaf4e395b1afda1
The root cause of the intermittent fail is because "DOMAudioPlaybackStopped" has no directly relationship with browser.mute()/unmute().
In [1], the "DOMAudioPlaybackStopped" is caused by audio stop playing, not by calling the browser.mute(). If the audio stops playing before calling the wait_for_event(), the test would be time-out. I guess the bug 1302280 is also caused by same reason.
So this patch would do two thinngs,
1. dispatch "DOMAudioPlaybackStopped" when we mute tab
2. loop the audio in test file, to make sure the "DOMAudioPlaybackStopped" is
dispatched when muting the audio, not the file ended.
[1] https://goo.gl/ymUv8P
MozReview-Commit-ID: 5RnyBRE73lQ
--HG--
extra : rebase_source : 40ad97cbf84da6f5d013d832cb12e3ed88473dfd
The root cause of the intermittent fail is because "DOMAudioPlaybackStopped" has no directly relationship with browser.mute()/unmute().
In [1], the "DOMAudioPlaybackStopped" is caused by audio stop playing, not by calling the browser.mute(). If the audio stops playing before calling the wait_for_event(), the test would be time-out. I guess the bug 1302280 is also caused by same reason.
So this patch would do two thinngs,
1. dispatch "DOMAudioPlaybackStopped" when we mute tab
2. loop the audio in test file, to make sure the "DOMAudioPlaybackStopped" is
dispatched when muting the audio, not the file ended.
[1] https://goo.gl/ymUv8P
MozReview-Commit-ID: 703JHj9dICT
--HG--
extra : rebase_source : ad2985bd14d6a9b91a73c0d4103aa51c4981124c
We don't have an MP4 demuxer that can handle VP9 in non-fragmented MP4. Jay's
change to DecoderTraits in Bug 1339204 will make MediaSource.isTypeSupported()
report that it can play VP9 in MP4. But we don't want to report that we can
play VP9 in MP4 in HTMLMediaElement.canPlayType(), as usually canPlayType() is
used with the intention to check for whether fragmented MP4 can be played. So
we need to special case canPlayType() so that it reports that it can't play
VP9 in MP4.
The upcoming Rust demuxer will be able to support VP9 in MP4, so once we've
enabled that, we can confidently report in canPlayType that we support VP9 in
MP4.
MozReview-Commit-ID: G0q5ho5N2wr
--HG--
extra : rebase_source : cd7a18ff3080b2c9bca90b6935b03bfa2c8d780f
