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
To make it easier to tell what HTMLMediaElement API functions sites' JS is
calling, we should add more mozlogs. This will make it easier to figure out why
things aren't playing.
MozReview-Commit-ID: 9eVvkagGNgf
--HG--
extra : rebase_source : 153a68f27ec5c2b17c3c5a9e31d54b98ccc1a1ea
To make it easier to tell what HTMLMediaElement API functions sites' JS is
calling, we should add more mozlogs. This will make it easier to figure out why
things aren't playing.
MozReview-Commit-ID: 9eVvkagGNgf
--HG--
extra : rebase_source : 6f117a036fc5ce10413660fb9fd5d418d74e159d
Previously, in IsInRanges, aIntervalIndex could have values between -1..length-1.
After the change, the values are in range 0..length, which makes it possible to use unsigned ints and avoid UB.
MozReview-Commit-ID: 39SIzXRHv91
--HG--
extra : rebase_source : d0efebb4bc13694eb7d2048cd2eae2d6386238cf
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
--HG--
extra : rebase_source : fa0bd85570746e60341e8e2d3f874f9bd30c0232
Mostly-mechanical additions:
- Log constructions&destructions, usually by just inheriting from
DecoderDoctorLifeLogger, otherwise with explicit log commands (for internal
classes for which DecoderDoctorTraits can't be specialized),
- Log links between most objects, e.g.: Media element -> decoder -> state
machine -> reader -> demuxer -> resource, etc.
And logging some important properties and events (JS events, duration change,
frames being decoded, etc.)
More will be added later on, from just converting MOZ_LOGs, and as needed.
MozReview-Commit-ID: KgNhHSz35t0
--HG--
extra : rebase_source : dd7206e350e32671adc6f3b9e54ebf777251de2c
We calculate 'canplaythrough' in ChannelMediaDecoder::DownloadProgressed() and
send updates to MDSM.
MozReview-Commit-ID: KAeDciPAUKs
--HG--
extra : rebase_source : 64d7705fb5ca6b1003664ac313ad1ae0ab1bbea6
Per UX spec, we would allow non-audible media (volume 0, muted, video without audio track)
to autoplay.
MozReview-Commit-ID: HKUyt5Jt4sH
--HG--
extra : rebase_source : 83e53a0035d72984494948f131a5d6e516baa577
If the media has started playing before, bless it and it would always be allowed
to autoplay.
MozReview-Commit-ID: 4GqMARLXULU
--HG--
extra : rebase_source : 2fdb3937156147755f8e387b1d84311ae1d37ce4
If the media has started playing before, bless it and it would always be allowed
to autoplay.
MozReview-Commit-ID: 28X4TmG25aJ
--HG--
extra : rebase_source : 3fd7cb16da9e7f925ad7020fb74c48537e08a996
The process of |TryRemoveMediaKeysAssociation()| is a 2-step async procedue in mainthread.
mMediaKeys might be set to null inside |NotifyOwnerDocumentActivityChanged()| in between
|TryRemoveMediaKeysAssociation| and |RemoveMediaKeys|.
MozReview-Commit-ID: HtiADt3UTvp
--HG--
extra : rebase_source : 9eff95040b3e900fb778187e4e432bce0b41396b
Per UX spec, we would allow non-audible media (volume 0, muted, video without audio track)
to autoplay.
MozReview-Commit-ID: HKUyt5Jt4sH
--HG--
extra : rebase_source : 97315d90fa46a16289135ac7490bd0dab651d682
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
--HG--
extra : rebase_source : c72212ebf29ea624128a8190dab67e1197f1f198
Per UX spec, we would allow non-audible media (volume 0, muted, video without audio track)
to autoplay.
MozReview-Commit-ID: HKUyt5Jt4sH
--HG--
extra : rebase_source : fa8d1bfd2fb667e974dbe499d7f8215273d4fa10
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
--HG--
extra : rebase_source : 5dba46f61d70ec647cae16383b62961ac72d2f47
We won't need to check the whether the media element is interacted with user for
autoplay anymore.
MozReview-Commit-ID: 2tll9LtGyVR
--HG--
extra : rebase_source : 0047f482c2932e7063fc556ce8c306ff276efbfd
AutoplayPolicy is used to manage autoplay logic for all kinds of media,
including MediaElement, Web Audio and Web Speech.
MozReview-Commit-ID: R1TxMkarIw
--HG--
extra : rebase_source : 8c608a1d12c8e205391a91f22e1532bc4f2c8f16
There are currently two types of sinks for a MediaStreamTrackSource.
Actual MediaStreamTracks and HTMLMediaElement::StreamCaptureTrackSource.
A source needs actual tracks as sinks to not stop() the underlying source.
A StreamCaptureTrackSource, however, should not count toward keeping a source
alive (otherwise HTMLMediaElement.mozCaptureStream() would prevent track.stop()
from working on the track feeding the media element).
MozReview-Commit-ID: 9MBAyZFZUIQ
--HG--
extra : rebase_source : a73f182b95281baf4f44f7ae82158e4a6bce42eb
This is a drive-by fix in that it is not directly related to what the bug is
solving. However, making HTMLMediaElement register as a sink is important,
and pairing it with the WeakPtr<Sink> patch reduces risk greatly.
MozReview-Commit-ID: 7pMDw3MG0ZB
--HG--
extra : rebase_source : e2f2b3a12b9921373518d94a083adda23bfe853b
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
--HG--
extra : rebase_source : 5d6633a2e1a456d2d619b6f68498065d94c68c40
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
--HG--
extra : rebase_source : e9922ac6064c953ee233d6829e84bc7828518b43
The MediaKeys status inside a HTMLME cannot be reflected correctly if the mSetCDMRequest is disconnected in HTMLME::ShutdownDecoder.
This may happen when a page calls load() or sets new src right after setting MediaKeys to null.
MozReview-Commit-ID: 3BZOmw7BNFO
--HG--
extra : rebase_source : f06ae54944133e8e48471e71f0bb8fe46290cca8
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
--HG--
extra : rebase_source : 74085dce2852d0a608f6455bd0b9337b8223fa20
The return value is unchecked in MediaDecoder, and we only ever returned
NS_OK anyway. And we if the dispatch fails, we can't really do anything;
dispatching an "error" event probably won't work.
MozReview-Commit-ID: 67K6Mjft6tY
--HG--
extra : rebase_source : ad644e8b97fc11488983bc05e18c9941b3c5b062
We queried 'loadingprincipal' attribute on the common call path, however
this should be queried if it's loaded by System Principal.
Also rename loadingprincipal to triggeringprincipal
MDSM doesn't reset the decoding pipeline of MFR when doing NextFrameSeek and
therefore fails the assertion by requesting video data while MFR is still seeking.
We put the fix in the media element because it doesn't make sense to do
NextFrameSeek while another seek is already in action.
MozReview-Commit-ID: D6FSiNWHrLU
--HG--
extra : rebase_source : 7793fa32fb5fe3406f235aa43908a8a96202ee6c
The old code doesn't print readyState changes when networkState is EMPTY.
MozReview-Commit-ID: 8rWUbpsmNuu
--HG--
extra : rebase_source : 509ebf1ae94e2618e63c764ef8fdf0869cb60582
Now DecoderTraits doesn't need to depend on ChannelMediaDecoder.
MozReview-Commit-ID: D4AUiV2eGWy
--HG--
extra : rebase_source : 38e6c4cdd0f7e32473c6945550bca6fd0cc72bf2
See comment 3 for the root cause.
MozReview-Commit-ID: CX5npKv2eWG
--HG--
extra : rebase_source : 085192f55b082f878d2f9915c24e89a56a981799
extra : source : 07f12b6df9d35eb3d215835a174504c70120b588
In order to tailor certain security checks to the caller that is attempting to
load a particular piece of content, we need to be able to attach an
appropriate triggering principal to the corresponding requests. Since most
HTML content is loaded based on attribute values, that means capturing the
subject principal of the caller who sets those attributes, which means making
it available to AfterSetAttr hooks.
MozReview-Commit-ID: BMDL2Uepg0X
--HG--
extra : rebase_source : 25e438c243700a9368c393e40e3a6002d968d6c8
(Path is actually r=froydnj.)
Bug 1400459 devirtualized nsIAtom so that it is no longer a subclass of
nsISupports. This means that nsAtom is now a better name for it than nsIAtom.
MozReview-Commit-ID: 91U22X2NydP
--HG--
rename : xpcom/ds/nsIAtom.h => xpcom/ds/nsAtom.h
extra : rebase_source : ac3e904a21b8b48e74534fff964f1623ee937c67
Also assert readyState is HAVE_NOTHING before creating a new decoder.
MozReview-Commit-ID: B0QACf96AA3
--HG--
extra : amend_source : ef4b41db04ee10f7eaae8f388d984ed0fd0863b5
Also assert readyState is HAVE_NOTHING before creating a new decoder.
MozReview-Commit-ID: B0QACf96AA3
--HG--
extra : rebase_source : f89bd84b130273ff734471619485d5f12a83006d
extra : source : 9b63f9eaa250ebe7259cc7fab709aac00858aaf6
These listeners will be AddRefed/Released off the main thread when
OMT data delivery is enabled.
MozReview-Commit-ID: CSOBgNNf3OW
--HG--
extra : rebase_source : d9085c6447e51d3aa9cad79fa1e25d986fdee792
extra : intermediate-source : 21be6f0003e6d3ccf4448e6574ea5d3122665155
extra : source : 8ce13766af359b5e55524e47ea74bcfc0e0133f8
We register the nsIWebProgressListener at the root docshell(GetSameTypeRootTreeItem) to handle video element embedded in iframe.
MozReview-Commit-ID: D4CavLDAnKD
--HG--
extra : rebase_source : 93032297272bbfc8570dce0c8c13ea9f0d45f7a8
Fix after an observed nullptr deref on try where mOutputStreams contained an
object whose mStream member had been nulled out.
MozReview-Commit-ID: 4kL1choTeW3
--HG--
extra : rebase_source : e4a6f600a66f00a963b19bf74717246c5099a784
MediaStreamGraph only implements the blocking notifications for SourceMediaStreams,
but the MediaStream that gets attached as srcObject on a media element is always
a TrackUnionStream. Hence, this code is unused and can be removed.
MozReview-Commit-ID: 6DKtCGNsZec
--HG--
extra : rebase_source : 0b3b7156a9e2e70933edadcc0a59c8fa81d49913
