We currently observe changes to HTMLMediaElement::mPaused via a hand-rolled
wrapper class. We can use use mozilla::Watchable<> and avoid rolling our
own equivalent here.
This also paves the way for using state watching on other observable state
in HTMLMediaElement.
MozReview-Commit-ID: 4lBlJiV15iG
We don't need to track this state anymore, as we don't need to delay calling
MediaDecoder::Play() or delay firing the "playing" event anymore.
MozReview-Commit-ID: E3B9l6ep7FP
We'd like to know the proportion of HTMLMediaElement.play() calls that are
rejected due to autoplay being blocked. There are also other conditions that
cause us to reject the promise returned by HTMLMediaElement.play(), so add
telemetry to report all the identifyable conditions under which play()
succeeds or fails.
MozReview-Commit-ID: AZ67WWXaowN
We want to block playback of media which have an audio track, so if play()
is called before the load of the resource has loaded metadata, we need to
delay starting playback and resolving the play promise until we've figured
out whether the media has audio. So if play() is called before we've reached
readyState >= HAVE_METADATA, set a flag, and check that flag when we do
reach HAVE_METADATA and start the play and resolve the promise then.
MozReview-Commit-ID: 1K06NK2kfpw
Our autoplay blocking is trivial to defeat; just mute or volume=0 a video,
play(), and then unmute, and then you're playing audibly.
So this patch makes us pause() media that become audible atfter playback
has started.
MozReview-Commit-ID: 2RAtbohMGJO
The changes in bug 1324883 regressed YouTube, so back them out.
The changes in bug 1324883 were trying to cause the media cache to be cleared
on tab close and on CTRL+F5 reload (i.e. a bypass cache-reload) but they are
causing problems on YouTube, which doesn't use the media cache and instead
uses MSE.
MozReview-Commit-ID: Hx2cehZ2wm1
This patch is mainly reverting the changing of bug1382574 part3, but not all the same.
Since youtube would call load() when user clicks to play, and then call play()
later. For the old pref (checking user-input-play), we should still allow the
following play() even it's not triggered via user input. It's also same for
seeking, Youtube would call play() after seeking completed.
In this patch, we would allow the script-calling once play() if user has called load()
or seek() before that.
MozReview-Commit-ID: 1UcxRCVfhnR
This is necessary in order to parse style attributes using the subject
principal of the caller, rather than defaulting to the page principal.
MozReview-Commit-ID: GIshajQ28la
This patch implements HTMLMediaElement::GetEventTargetParent and set
aVisitor.mCanHandle to false to mouse/touch/pointer events, when
the media control is present. This tells the event dispatcher that
these events are supposed to be handled exclusively by the
videocontrol binding within the media element, and should not
dispatch nor consumed by the content.
MozReview-Commit-ID: BXWZX9SYsuC
This patch implements HTMLMediaElement::GetEventTargetParent and set
aVisitor.mCanHandle to false to mouse/touch/pointer events, when
the media control is present. This tells the event dispatcher that
these events are supposed to be handled exclusively by the
videocontrol binding within the media element, and should not
dispatch nor consumed by the content.
MozReview-Commit-ID: BXWZX9SYsuC
1. move all checks to CanActivateAutoplay()
2. don't cache the pref's value in advance, it might cause wrong result
if user changes pref after media was binded to tree.
MozReview-Commit-ID: 3BeOeaq9wGa
