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
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
--HG--
extra : rebase_source : 6a2913e5d81591faf1a7383d9fcb9db2cf3f83d3
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
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
--HG--
extra : rebase_source : 3156abdcd5c57932e8edb61e78ffb568e4edbf2a
They are not unstoppable any longer. We just don't forward Stop() to the real source.
MozReview-Commit-ID: FdFccMsD3eb
--HG--
extra : rebase_source : e29a1abb8f2060cb72399d61d91ca3a00128f08c
MediaStreamTrack.remote is no longer part of the spec.
MozReview-Commit-ID: BgHJ1zNIoWN
--HG--
extra : rebase_source : 11022eb420cbdb0c7aa5aa7814cf35330f4170b9
This makes sense because the result of StreamListener::NextFrameStatus depends
on mElement.
MozReview-Commit-ID: 8W7nGLpRxE1
--HG--
extra : rebase_source : 48f9c3c637eb01430446dbaf683e65008df19147
Better semantics for what I want to do with NotifyEnded in later patches in the bug.
MozReview-Commit-ID: 8X0BdiVncNo
--HG--
extra : rebase_source : f36f5a17f2294c6ad9b5db2593b41eb8cd8a9a15
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 : a13fd5fa570a6868af6c3ed7b3dbfab173a9ffef
Otherwise, when a value="" attribute with a newline in it is copied, we
will strip any newlines even if type="hidden" is set, because type=""
hasn't yet been copied. Other bugs are likely too. This problem was
already solved for the parser, so we can just use that solution for
cloning too.
MozReview-Commit-ID: KqxCnxmxFXp
--HG--
extra : rebase_source : 9a666adad3dbbbaa5e3706747dcf70801b9ef4e8
The spec used to say that getting the .ping property on
HTMLAnchorElement or HTMLAreaElement should return a DOMTokenList of
parsed URLs, but it now says to return a plain string. All other UAs
that implement ping match the new spec, and it's hopefully unlikely that
any sites depend on our old behavior.
Discussion: https://github.com/whatwg/html/issues/1780
MozReview-Commit-ID: LpmH8ANNT9g
--HG--
extra : rebase_source : 117021a026d7a1716fa7a705e9417797297697ab
The specification doesn't require there to be a 'type' member of
the keyids init data format.
MozReview-Commit-ID: 7mOm7KwyyuC
--HG--
extra : source : c9fb674f3cb8dff4fe8734e0426e67825878015d
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
--HG--
extra : rebase_source : e615e17d49bd35ecb9cb7db84501489ec5e12903
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
The specification doesn't require there to be a 'type' member of
the keyids init data format.
MozReview-Commit-ID: 7mOm7KwyyuC
--HG--
extra : rebase_source : 88b729ae0b0f851763bbd06ec48bae2d6ac1c47e
