It's possible that if the HTMLMediaElement is loading while we're loading a new
document into a docshell, that the HTMLMediaElement can reach readyState
HAVE_FUTURE_DATA just after its OwnerDoc is removed from the docshell. If the
HTMLMediaElement wasn't paused, then it may start playing due to the readyState
change in HTMLMediaElement::ChangeReadyState().
For years we've had hard to reproduce issues where media started playing after
we've closed the tab; I bet this was the cause!
When we detect that the document has been removed from its DocShell,
HTMLMediaElement::NotifyOwnerDocumentActivityChanged() is called, and that
suspends the MediaDecoder just in case we need to resurrect the media element,
for example if the tab comes out of the BF cache. When we suspend we set
mPausedForInactiveDocumentOrChannel=true, and all other calls to
MediaDecoder::Play() are guarded by checks on
mPausedForInactiveDocumentOrChannel.
So we should also guard the MediaDecoder::Play() call in ChangeReadyState()
with a check on mPausedForInactiveDocumentOrChannel too.
MozReview-Commit-ID: GfmZasT9jdr
--HG--
extra : rebase_source : 5539503795868e9496fe34014b5c04d2ed48241b
extra : source : e94884022fa7df95adf90e44a44e4f168d60f01a
It's possible that if the HTMLMediaElement is loading while we're loading a new
document into a docshell, that the HTMLMediaElement can reach readyState
HAVE_FUTURE_DATA just after its OwnerDoc is removed from the docshell. If the
HTMLMediaElement wasn't paused, then it may start playing due to the readyState
change in HTMLMediaElement::ChangeReadyState().
For years we've had hard to reproduce issues where media started playing after
we've closed the tab; I bet this was the cause!
When we detect that the document has been removed from its DocShell,
HTMLMediaElement::NotifyOwnerDocumentActivityChanged() is called, and that
suspends the MediaDecoder just in case we need to resurrect the media element,
for example if the tab comes out of the BF cache. When we suspend we set
mPausedForInactiveDocumentOrChannel=true, and all other calls to
MediaDecoder::Play() are guarded by checks on
mPausedForInactiveDocumentOrChannel.
So we should also guard the MediaDecoder::Play() call in ChangeReadyState()
with a check on mPausedForInactiveDocumentOrChannel too.
MozReview-Commit-ID: GfmZasT9jdr
--HG--
extra : rebase_source : dba32e8341a3dd70355ccdd7fd8790911a92acc8
extra : source : e94884022fa7df95adf90e44a44e4f168d60f01a
This patch is an automatic replacement of s/NS_NOTREACHED/MOZ_ASSERT_UNREACHABLE/. Reindenting long lines and whitespace fixups follow in patch 6b.
MozReview-Commit-ID: 5UQVHElSpCr
--HG--
extra : rebase_source : 4c1b2fc32b269342f07639266b64941e2270e9c4
extra : source : 907543f6eae716f23a6de52b1ffb1c82908d158a
Sometimes when video is playing, a preroll ad plays, and that may be in a cross
origin iframe. If autoplay media is disabled, we require a user gesture in a
document before playback in that document is permitted, and we require each
origin to be gesture activated separately. So in the cross origin preroll video
add case, then the user will have to click once to unblock playback for the
cross origin ad, and then once the preroll ad finishes, the user will have to
click again to activate playback of the same origin content video.
This is a bad user experience.
So we should instead make gesture activation propagate up the doc tree
irrespective of crossing origins. This way, when the user clicks to activate,
all documents in that tab are also also effectively gesture activated, and so
can autoplay.
MozReview-Commit-ID: 1HZQ5zkubR
--HG--
extra : rebase_source : d6b75732548cb1d73b9f82dce60a5e6e97d1da14
SeekToNextFrame is handled differently than other seeks by the
MediaDecoderStateMachine, and should not take place while other seeks already
are. Bug 1410225 implemented some changes in HTMLMediaElement to prevent this,
but it's still possible to move to a seeking state in the MDSM and accept
SeekToNextFrame (as in this bug).
This changeset changes the MDSM to reject SeekToNextFrame if a seek is already
happening. Since the MDSM now does this the changes from bug 1410225 can be
removed.
This has the functional change of the promise from SeekToNextFrame being
rejected if the seek in not performed due to another seek. Previously the
promise would succeed when the other seek completed. This seems sensible as the
next frame seek does not actually take place.
MozReview-Commit-ID: HD9WRFq3LZV
--HG--
extra : rebase_source : fb276010119038db4319b3b81bcbf51ef2cab1d9
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
--HG--
extra : rebase_source : 22f9d811371f9d609dc96a9d958645e5c634eb17
extra : intermediate-source : bdb8280da440a711c6cd51b65ead7ba9e4bb3597
extra : source : fd8c4b8656a9996eea94d2092caaf3c10fe2a835
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
--HG--
extra : rebase_source : 63df836bf0249ed40b0659cd42794e92966cefb9
I don't think we should allow media without audio tracks to autoplay because:
* It means play() before loaded metadata behaves differently than play()
called after loaded metadata.
* With the current impl we dispatch the "play" event and then the "pause"
event when we decide we should block, which may confuse some sites' controls.
* Delaying running the play() algorithm until we've loaded metadata would add
significant complexity, and may break sites.
* Chrome doesn't have this provision, meaning the complexity required to
support it will not result in much benefit to us.
MozReview-Commit-ID: FSVlDJAOisw
--HG--
extra : rebase_source : 93b1bcf8d8edbd6ca10ad918b40a87cd3cfbbf0b
This patch splits FontTableURI and BlobURL in 2 classes:
FontTableURIProtocolHandler and BlobURLProtocolHandler
both under mozilla::dom.
It also removes a memory reporter because that report is already covered by the
BlobURL one.
--HG--
rename : dom/file/nsHostObjectProtocolHandler.cpp => dom/file/BlobURLProtocolHandler.cpp
rename : dom/file/nsHostObjectProtocolHandler.h => dom/file/BlobURLProtocolHandler.h
Same approach as the other bug, mostly replacing automatically by removing
'using mozilla::Forward;' and then:
s/mozilla::Forward/std::forward/
s/Forward</std::forward</
The only file that required manual fixup was TestTreeTraversal.cpp, which had
a class called TestNodeForward with template parameters :)
MozReview-Commit-ID: A88qFG5AccP
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
When using a media element with a Media Source, the resource fetching algorithm is to be called in "local" mode:
https://www.w3.org/TR/media-source/#mediasource-attach
"Continue the resource fetch algorithm by running the remaining "Otherwise (mode is local)" steps, with these clarifications"
https://html.spec.whatwg.org/multipage/media.html#concept-media-load-resource
Under the local mode, the steps that would cause the element to fire suspend, stalled or progress can never occur.
We only prevent the stalled event to be fired, many websites rely on the progress event to be fired (such as when the init segment has been parsed). The HTML5 media spec will be amended to clearly indicate that progress is to be fired even with mediasource
MozReview-Commit-ID: DkoQzoV0JzO
--HG--
extra : rebase_source : 1e916eee50c9935f168797bb5a92052191cda59d
Partially apply clang-format so that we limit the scope of changes while ensuring consistency in declarations.
MozReview-Commit-ID: Km9sKBbFhKx
--HG--
extra : rebase_source : 880e1fc1b46ab57d961e12eb7670260128d0faa1
Currently we can end up dispatching a 'playing' event right before we reject
play() promises, and this confuses YouTube's controls, and it doesn't make
sense to dispatch a 'playing' event when we're not playing anyway.
This is because the logic to delay resolving the play() promise until after
we've reached loadedmetadata doesn't prevent the 'playing' event from being
dispatched. We shouldn't dispatch 'playing' until we resolve the play()
promise(s).
MozReview-Commit-ID: 5H4dcObfu4M
--HG--
extra : rebase_source : b4036a8fead95cd3070f9fc4d30e0feb23d1f64c
We already reject the play promises when we call Pause(), so this extra
reject is unnecessary.
MozReview-Commit-ID: 6LKw7hCwJPH
--HG--
extra : rebase_source : b75c147c2f475cf1ae4b4dddc3085c306f31d6e6
Bug 1435133 introduced a new path where we block autoplay and reject the play()
promise, but we didn't fire a "pause" event. This confuses YouTube's controls.
Additionally, even if we're not in a user generated event handler, we
unilaterally consider the media element blessed if execution reaches here:
https://searchfox.org/mozilla-central/rev/11a2ae294f50049e12515b5821f5a396d951aacb/dom/html/HTMLMediaElement.cpp#4110
We previously rejected before reaching here when not in a user generated event
handler, but now if play() is called before we've reached loadedmetadata, we
reject the promise if we're not in a non-event handler and bail out early, and
so we'll bless even if not in a user generated event handler. Meaning when we
do reach loadedmetadata, we think we were in a user generated event handler
when play() was originally called, and so we won't reject the play promise.
So this patch ensures we dispatch a "pause" event when we reject the play()
promise here. The WHATWG spec says we should do this when pausing anyway.
Note: calling our interal Pause() function when rejecting the play() promise
here breaks YouTube, as if we do that we fire a "timeupdate" event. So I opted
to manually code to fire the event here instead of just calling Pause()
everywhere we want to ensure we're paused.
MozReview-Commit-ID: 1snkiTnPGih
--HG--
extra : rebase_source : 2c5ca6c0ed7c2dff2fb971cd159cfdc12a8a227f
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
--HG--
extra : rebase_source : 4a164cb0b4fb7fb6944cd371c6e90dde021a4dc0
This patch converts all the prefs in MediaPrefs to the new StaticPrefs system.
Note that the "media.wmf.skip-blacklist" pref was present in both MediaPrefs
and gfxPrefs. The copy in MediaPrefs was never used; this explains why this
patch does not add an entry for it to StaticPrefList.h.
Note also that the patch removes themedia.rust.mp4parser pref, because it's
unused.
MozReview-Commit-ID: IfHP37NbIjY
--HG--
extra : rebase_source : df84ea813b7c366d7be663c696891325610149c8
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
--HG--
extra : rebase_source : 45636e77b44ed072e1bc3f1e9a9f73f206ee04de
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
--HG--
extra : rebase_source : 021510102374185debc89610bc6027206a0af6fc
