W3C HTML5 spec isn't very actively maintained now. WhatWG HTML spec:
When a media element is removed from a Document, the user agent must run the following steps:
Below is the related statement in WhatWG HTML spec:
Await a stable state, allowing the task that removed the media element from the Document to continue. The synchronous section consists of all the remaining steps of this algorithm. (Steps in the synchronous section are marked with ⌛.)
⌛ If the media element is in a document, abort these steps.
⌛ Run the internal pause steps for the media element.
MozReview-Commit-ID: H4EgPqj2YxD
--HG--
extra : rebase_source : 4f875b7cbd0ead4cf0d8ce191a3ba32fb6f6395b
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
4.8.12.5
https://html.spec.whatwg.org/multipage/embedded-content.html#media-element-load-algorithim
The living WHATWG spec has been changed since I implemented this patch.
Will update to the latest spec later.
MozReview-Commit-ID: 7U1AC2Ua83Z
--HG--
extra : rebase_source : d4b7c5103b29271cfdde5d180d7e7c8a65d89b2f
extra : intermediate-source : 616bc473295c8673e3cfae726b8a19c64b2906f1
extra : source : 69d8b411ee5f85139f3f40ce4bc7a4d7ad018b8d
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
http://searchfox.org/mozilla-central/rev/dc8cf05768b83a6ef0b4039edd6efddd56ee4109/dom/media/MediaDecoderStateMachine.cpp#1065
Changing nextFrameStatus to UNAVAILABLE might change readyState to HAVE_CURRENT_DATA and cause 'waiting' to fire.
It doesn't make sense to fire 'waiting' at the end of playback.
http://searchfox.org/mozilla-central/rev/dc8cf05768b83a6ef0b4039edd6efddd56ee4109/dom/html/HTMLMediaElement.cpp#5423
Note the check for Ended() doesn't work as expected to prevent 'waiting' from firing at the end of playback
because of the way how TailDispatcher schedules stateChange tasks.
This patch keeps readyState in HAVE_ENOUGH_DATA when playback is near the end for wanting no more data.
readyState will change to HAVE_CURRENT_DATA when the playing state of MediaDecoder is changed to PLAY_STATE_ENDED.
MozReview-Commit-ID: 6EspaD2hhx
--HG--
extra : rebase_source : 345aad2757d684e24863ae2daf506b035955efe7
extra : source : 56736efbab04a5c2d66faf2514bac93acf4c79f7
The crash reason seems the mOwner has been released, so we shouldn't call any method which would call mOwner.
The AudioChannelAgentCallback could only be called from two parts, one is from mOwner, another is from AudioChannelService (via AudioChannelAgent).
We don't want this class be called after mOwner was released, we should disconnect it from AudioChannelService.
Calling NotifyStoppedPlaying() can unregister agent from service, so service won't call agent anymore.
Therefore, no one would call AudioChannelAgentCallback after CC happened.
MozReview-Commit-ID: 7HY4KpciacB
--HG--
extra : rebase_source : 228c4988cd5aaae7b8b5c10463eb8445a8771d62
We need to end the synchronous section when the src attribute is empty and then run the "failed with elements step" in non-sync section.
MozReview-Commit-ID: DJ7GYqa6aI5
--HG--
extra : rebase_source : 41f4312408a62497a52e301cfacc2ac209e89bd4
These comments should be removed after landing bug1302350.
MozReview-Commit-ID: 7N0cWImZDDI
--HG--
extra : rebase_source : ee78246f4bb7f7a1dc2c95f08295e5159312f498
If input is a media stream, we would always regard it as audible when it's playing.
We won't need to set it as non-audible.
MozReview-Commit-ID: 8mzTsAkt6lG
--HG--
extra : rebase_source : f406542c2b8a9a349e14d199108d37ce57e9a223
In previous patch, we removed UpdateAudioChannelPlayingState() from AddRemoveSelfReference(), now we
don't call UpdateAudioChannelPlayingState() during the seeking. So we don't need to afraid to stop
audio channel agent during the seeking.
MozReview-Commit-ID: GTuIRB24zlq
--HG--
extra : rebase_source : fb09137fd578adc9332eff8eee41891980157cf9
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
These comments should be removed after landing bug1302350.
MozReview-Commit-ID: 7N0cWImZDDI
--HG--
extra : rebase_source : b259780a2c901449d72dfcf1280de72cae890ade
If input is a media stream, we would always regard it as audible when it's playing.
We won't need to set it as non-audible.
MozReview-Commit-ID: 8mzTsAkt6lG
--HG--
extra : rebase_source : 2eaa6f1d92ef2f4048fae61ed99739157cf08287
In previous patch, we removed UpdateAudioChannelPlayingState() from AddRemoveSelfReference(), now we
don't call UpdateAudioChannelPlayingState() during the seeking. So we don't need to afraid to stop
audio channel agent during the seeking.
MozReview-Commit-ID: GTuIRB24zlq
--HG--
extra : rebase_source : 20cae16efabd296f4b3c404886364aaa92db5df6
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
The previous changeset against this bug relaxed the conditions under which the
CDM and associated objects were shut down. This was to address moving a tab to a
new window breaking EME videos. However, this had the unwanted side effect of
not shutting down those objects early enough when pages are closed.
This changeset introduces a new check to see if the containing document is
currently active, if not we shutdown the CDM. This means CDMs are shutdown on
time, while retaining the desired behaviour that CDMs should not be shut down on
moving tabs to new windows. Shutdowns previously happened because we shut down
if a page hide happened, which took place during a reparent.
MozReview-Commit-ID: K5CD3ej43Y0
--HG--
extra : rebase_source : 28fdc277a89c371ad204d5e545779a5950063494
This changeset relaxes the shutting down of decoders and removal of mediakeys
when suspending HTMLMediaElements. This should now only happen for adobe
primetime. This alleviates, for non-primetime CDMs, the issue of videos
breaking when moving an EME protected video from a tab to a new window.
These conditions can be relaxed as neither clearkey or widevine support
secure stop. This means we don't need to shutdown their decoders and keys to
signal a stoppage, as at this stage, doing so doesn't give us secure stop and
instead means that playback is busted when we try to resume.
MozReview-Commit-ID: 3MGNXGGDVLS
--HG--
extra : rebase_source : cbf46b3da089f79d9b6729a02997d1a0a12b68a7
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
Because audio channel agent uses weak ref to HTMLMediaElement, so we don't need to add it into the CC list.
MozReview-Commit-ID: 4cFfDUlbMFB
--HG--
extra : rebase_source : 4d595397d11e2e3c46cce17df148bea8f77f92e8
