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
