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
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
Under some circumstances, we will go from NEXT_FRAME_AVAILABLE to NEXT_FRAME_UNAVAILABLE_BUFFERING directly. We handle this condition now
MozReview-Commit-ID: JVAQhsgzSp2
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
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
Regression by bug1262053 because of removing the current playing checking.
It would cause that the media control on Fennec shows too early and some media
elements would also generate the media control even it doens't have available
source.
Therefore, I think we still need to add this checking back.
MozReview-Commit-ID: 1m1ywmLmpSe
8eef5d2cc850 in Bug 1300654 incorrectly resolved a merge conflict and backed
out part of the fix for Bug 1280829. Relanding.
MozReview-Commit-ID: 6DIkUrc9R4t
Also replace the check for IsPotentiallyPlaying() with !mPaused because mReadyState >= HAVE_FUTURE_DATA guarantees playback is not ended.
MozReview-Commit-ID: HetaVDgYEW0
Previously, we'd block loading of non-MSE content when there was a MediaKeys
attached, that is, we'd assume that all content was EME content if a MediaKeys
was attached. But some sites attach a MediaKeys and then load non-MSE non-EME
content, and that (despite being a bit silly) shouldn't fail.
MozReview-Commit-ID: 9LupWaehXim
