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
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
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
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
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
Similar to DecodeError, except we allow decoding to continue.
MozReview-Commit-ID: FN9m03o6GXV
--HG--
extra : rebase_source : a6ca0cc28d2990ab143676758cd880baaca7bcb7
Dispatch |QueueLoadFromSourceTask| to main thread to make sure the task will be executed later than loadstart event. And when the src get errors, we need to end the synchronous section.
MozReview-Commit-ID: EQ0jVIMnqoZ
--HG--
extra : rebase_source : 876c62669f56581e903830beddbf0ce4435366e2
Dispatch |QueueLoadFromSourceTask| to main thread to make sure the task will be executed later than loadstart event. And when the src get errors, we need to end the synchronous section.
MozReview-Commit-ID: EQ0jVIMnqoZ
--HG--
extra : rebase_source : 6651826ad8de361deda5bdc0a49b2c68dcf86220
In this patch, the following utilities are implemented:
(1) A list to keep pending promises of a HTMLMediaElement.
(2) A method to take pending promises out from the HTMLMediaElement.
(3) A global function to resolve the passed promises.
(4) A global function to reject the passed promises with an error code.
(5) A method to asynchronously resolve all pending promises of a HTMLMediaElement.
(6) A method to asynchronously reject all pending promises of a HTMLMediaElement.
(7) A method to dispatch a 'playing' event and resolve all the pending play promises.
All the above functionalities are defined at WHATWG 4.8.12.8:
https://html.spec.whatwg.org/multipage/embedded-content.html#list-of-pending-play-promises
This patch also implements two MediaEvent classes, nsResolveOrRejectPendingPlayPromisesRunner and nsNotifyAboutPlayingRunner, which help (5), (6) and (7).
This patch also implements a list of already-dispatched nsResolveOrRejectPendingPlayPromisesRunner; we keep tracing these tasks because the load algorithm resolves/rejects all already-dispatched pending play promises (in patch 2).
MozReview-Commit-ID: EUirNqDfttk
--HG--
extra : rebase_source : e48196e77341926900747b3f9477c5ee9ed28f62
extra : intermediate-source : 9b349c0e9eedad8822a1b8e8ef375ac6cb0b635a
extra : source : 75ee3b084edb68709503c98ad7b72850af7bb9c8
UpdateAudioChannelPlayingState() should only be called when following attributes changed.
eg. pause/ready state/error/owner document's visibility/exteral source stream.
Therefore, we don't need to call this function in FinishDecoderSetup() and AddRemoveSelfReference().
Remove AutoNotifyAudioChannelAgent is because now we don't check HasAudio() for IsPlayingThroughTheAudioChannel().
MozReview-Commit-ID: 4VTHIAdAqX1
--HG--
extra : rebase_source : 5ee4cabd543fe43b4e51fa4ce68af083c8fd8e1a
In order to keep the media element's code clear (spec code only), we want to remove our
custom policy code out from media element. This new class will handle all audio channel
related stuffs, eg. mute/unmuted operation from tab audio indicator, play/resume from
Fennec's media control.
MozReview-Commit-ID: 5mDqDBTnBOr
--HG--
extra : rebase_source : cdb0a4b67c3e96bede79f61cc9d79b920517f139
UpdateAudioChannelPlayingState() should only be called when following attributes changed.
eg. pause/ready state/error/owner document's visibility/exteral source stream.
Therefore, we don't need to call this function in FinishDecoderSetup() and AddRemoveSelfReference().
Remove AutoNotifyAudioChannelAgent is because now we don't check HasAudio() for IsPlayingThroughTheAudioChannel().
MozReview-Commit-ID: 4VTHIAdAqX1
--HG--
extra : rebase_source : 7f196581fb2e5a7e75afef27d874522986d2cdc5
In order to keep the media element's code clear (spec code only), we want to remove our
custom policy code out from media element. This new class will handle all audio channel
related stuffs, eg. mute/unmuted operation from tab audio indicator, play/resume from
Fennec's media control.
MozReview-Commit-ID: 5mDqDBTnBOr
--HG--
extra : rebase_source : e9d4c3a41ce9a994ef4d44f059537a69f27c7c1e
On Fennec, we would use external app (Android view) to play the media whih is
unsupported by gecko. We implement some special logic in error sink.
(1) dispatch "OpenMediaWithExternalApp" event
we use this event to start the android video player
(2) doesn't dispatch "error" event
some JS players won't let user to trigger play() again after receving the "error".
So we don't dispatch that event if we want to play the unsupported media more than once.
MozReview-Commit-ID: 7fZK5hdvaOG
--HG--
extra : rebase_source : 929db331c22e31a74f76dfa89a99a8adac65d0f6
Error sink would be response for the error handling, we could write different
error dispatching stragedies for different situation. eg. if we can play
unsupported type media with external app, we won't dispatch the "error" event on fennec.
MozReview-Commit-ID: Lm4x9ksspAY
--HG--
extra : rebase_source : 05331714425ea111d21f06fc03abfc1b016654ca
The first checking condition in the IsAllowedPlay() is used to prevent the play() operation
is called by untrusted JS when media.autoplay.enabled=false. Therefore, we don't need to check
that in CanActivateAutoplay().
MozReview-Commit-ID: 6yqoG8ISyra
--HG--
extra : rebase_source : a3e52a1a5591691f503d7d4ca78dda63c05aef27
Because the agent's initialization might fail if we don't get the valid inner window, we need to
check whether the agent exists before calling the agent's method.
MozReview-Commit-ID: IUuvyGh7CMd
--HG--
extra : rebase_source : 54d0811aad736abdbac5ae7c3cd8cfebed88923a
We don't want to stop the loading process even we canceled the play operation.
MozReview-Commit-ID: FyPqBlDKYo0
--HG--
extra : rebase_source : fdbc4390a7763bdbe26e8b809d977234bb5360ea
The old way is to start playing first, and then block the media element. This
way is too complicated because it involves lots of interal state and isn't intuitive.
The new way is to ignore the play if the media element should be blocked. It's
easy to know and we doesn't need to keep any internal states because we don't play
the media element.
MozReview-Commit-ID: B20e0pvXES4
--HG--
extra : rebase_source : 6bff5447783c2997050e5c69884afe2c85ddf382
We create audio channel agent in the beginning in oreder to use some agent's methods.
But the agent is still started after media element starting playing.
MozReview-Commit-ID: KPGb7snB2t7
--HG--
extra : rebase_source : dba4b687f572d520481721f48a0b4e9796f73e1f
We uses "media-playback" event to notify fennec media control about media start
and end. However, if we resume media which was paused by media control, it won't
send any notification to JAVA side so that the MediaControlService can't change
the correct playing icon.
Therefore, we create new event to inform this situation.
MozReview-Commit-ID: zScaHxvHXM
--HG--
extra : rebase_source : e1434840de36d8621a58fc7406b0f42673a2f3db
This means 'waitingforkey' will be fired at a predictable time.
MozReview-Commit-ID: HMt1RbgrbuR
--HG--
extra : rebase_source : cb8c36eacd3e78ae5105cd30da7a51d8241dbd5b
Since I want to use more agent's functions in MediaElement and I don't think these functions need to be exposed on IDL level. (for other languages binding)
Therefore, I want to use AudioChannelAgent directly in MediaElement.
MozReview-Commit-ID: 43FvDeLpZPt
--HG--
extra : rebase_source : 78741d791eb66cfb6223866ce823f217e3438fdb
Kaku Kuo
Iris Hsiao
JW Wang
karo
Gerald Squelart
Bevis Tseng
ctai
Carsten "Tomcat" Book
Alastor Wu
Kaku Kuo
Wes Kocher
Andreas Pehrson
Chris Pearce