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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Since the agent is created in beginning in patch1, we need another way to know
whether we have already called notifyStartedPlaying().
MozReview-Commit-ID: 5YNhwEl5Xfp
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
It needs an extra guard for when we're an audio element and a live video track
was removed. That's ok and we should ignore it.
MozReview-Commit-ID: FVw3lDKd4oU
