We're allowed to take some liberties as to what the default value and behaviour
we assume for the 'preload' attribute on HTMLMediaElement by the spec. On
desktop we assumed preload="metadata", while on mobile we assumed the default
of preload="none" to save data. On mobile we also assumed that preload="auto"
meant preload="metadata".
I think it makes sense to instead of always assuming that data on Android is
always expensive, we can instead detect if we're running on a cellular connection,
and preload frugally then, otherwise aggressively.
Differential Revision: https://phabricator.services.mozilla.com/D26235
--HG--
extra : moz-landing-system : lando
We're allowed to take some liberties as to what the default value and behaviour
we assume for the 'preload' attribute on HTMLMediaElement by the spec. On
desktop we assumed preload="metadata", while on mobile we assumed the default
of preload="none" to save data. On mobile we also assumed that preload="auto"
meant preload="metadata".
I think it makes sense to instead of always assuming that data on Android is
always expensive, we can instead detect if we're running on a cellular connection,
and preload frugally then, otherwise aggressively.
Differential Revision: https://phabricator.services.mozilla.com/D26235
--HG--
extra : moz-landing-system : lando
Per the discussion in:
https://groups.google.com/d/msg/mozilla.dev.platform/P79pwa9z5m8/iPYPAWPHCAAJ
They should be CamelCase, and that's what most of them already do. This converts
the rest, which are a few.
For the ones that already used `e` or `k` prefixes, I've mostly done:
for file in $(rg Type::e layout | cut -d : -f 1 | sort | uniq); do sed -i 's#Type::e#Type::#g' $file; done
For the ones that used uppercase, I've removed the prefix if it was already in
the type name, and turn them into CamelCase.
Depends on D28680
Differential Revision: https://phabricator.services.mozilla.com/D28681
--HG--
extra : moz-landing-system : lando
In order to make the implementation more fitting with the spec, move the implementation of `pending-text-track-change-notification-flag` from text track list to media element.
In addition, it also help us not to expose the internal flag `show-poster` (which will be implemented in patch3) of media element when doing the related algorithm.
Differential Revision: https://phabricator.services.mozilla.com/D21810
--HG--
extra : moz-landing-system : lando
In order to make the implementation more fitting with the spec, move the implementation of `pending-text-track-change-notification-flag` from text track list to media element.
In addition, it also help us not to expose the internal flag `show-poster` (which will be implemented in patch3) of media element when doing the related algorithm.
Differential Revision: https://phabricator.services.mozilla.com/D21810
--HG--
extra : moz-landing-system : lando
In order to display blocking icon when the document comes back from the bfcache, we have to notify front end what's the current blocking status.
As the front end side would clear blocking autoplay information when nagivation occurs, and the media might not invoke the play again when they comes back from the bfcache.
Therefore, we should notify front end side that the site is still being blocked, and we should show blocking icon for it.
Differential Revision: https://phabricator.services.mozilla.com/D21582
--HG--
extra : moz-landing-system : lando
By adding the Telemetry to measure the number of video/audio which played exactly 7 seconds or more, or less than 7 seconds, after those media has been resumed from blocked state, we can know how many media would meet the Chrome's MEI condition, which could help us to know more about the whole landscape of autoplay media.
In addition, it could help us know how many media are played 'by users intention' because we assume that users are more likely to stop the media if autoplay media is unblocked by accident.
Differential Revision: https://phabricator.services.mozilla.com/D18628
--HG--
extra : moz-landing-system : lando
If media element is used as a source for AudioContext, we would try to start AudioContext which was not allowed
to start when media element starts playing.
Differential Revision: https://phabricator.services.mozilla.com/D14593
--HG--
extra : moz-landing-system : lando
Wrap 'nsContentUtils::ReportToConsole()' to reduce necessary input parameters and call it when we need to log error or warning message. Show the warning when autoplay is blocked.
For web audio, this restores the console messages removed in part4 and also reports the same message when the AudioContext is blocked in the constructor.
Differential Revision: https://phabricator.services.mozilla.com/D14330
--HG--
extra : moz-landing-system : lando
Summary: Really sorry for the size of the patch. It's mostly automatic
s/nsIDocument/Document/ but I had to fix up in a bunch of places manually to
add the right namespacing and such.
Overall it's not a very interesting patch I think.
nsDocument.cpp turns into Document.cpp, nsIDocument.h into Document.h and
nsIDocumentInlines.h into DocumentInlines.h.
I also changed a bunch of nsCOMPtr usage to RefPtr, but not all of it.
While fixing up some of the bits I also removed some unneeded OwnerDoc() null
checks and such, but I didn't do anything riskier than that.
This removes DecodedStream's use of MediaStreamListener in favor of
MediaStreamTrackListener. This change has however rippled through to a lot
more cleanup, per below.
This moves the MediaStreamTrack lifetime ownership for captured
HTMLMediaElements from the media element to DecodedStream, where the
MediaStreamGraph-side tracks are already created and ended today.
This makes MediaStreamTrack creation explicit across the entire codebase and
lets us remove the MediaStreamTrackSourceGetter class and the infrastructure
of adding MediaStreamTracks after they've already been created in the graph
from DOMMediaStream.
With track ownership, and thus TrackID allocation ownership, happening
exclusively in DecodedStream for its output tracks, we also stop throwing
away and recreating the SourceMediaStream to which we feed data on seek.
This is one step closer to fixing bug 1172394 and spec compliance of
HTMLMediaElement.captureStream().
Differential Revision: https://phabricator.services.mozilla.com/D12273
--HG--
extra : moz-landing-system : lando
It was possible for two sequential calls to HTMLMediaElement::AddRemoveSelfReference to leave the media element deregistered when it should have registered.
And we ensure to ony ever self register once.
Differential Revision: https://phabricator.services.mozilla.com/D11859
--HG--
extra : moz-landing-system : lando
HTMLMediaElement::UpdateWakeLock() is responsible for creating and releasing audio wakelock.
HTMLVideoElement::UpdateWakeLock() is responsible for creating and releasing video wakelock.
In addition, each platform would handle system wakelock properly depending on different requests.
Differential Revision: https://phabricator.services.mozilla.com/D7214
--HG--
extra : moz-landing-system : lando
Various places in dom/ use the pattern:
already_AddRefed<NodeInfo> ni = ...;
which is supposed to be disallowed by our static analysis code, but
isn't, for whatever reason. To fix our static analysis code, we need to
eliminate instances of the above pattern.
Unfortunately, eliminating this pattern requires restructuring how Nodes
are created. Most Node subclasses take `already_AddRefed<NodeInfo>&` in
their constructors, and a few accept `already_AddRefed<NodeInfo>&&`. We
need to enforce the latter pattern consistently, which requires changing
dozens of source files.
"blocked" event is used for testing.
"MozAutoplayMediaBlocked" event is used for changing the control UI on Fennec.
Differential Revision: https://phabricator.services.mozilla.com/D4267
--HG--
extra : moz-landing-system : lando
Add two telemetry scarlar,
"MEDIA_BLOCKED_NO_METADATA" records how many media which was blocked because it hadn't loaded metadata yet.
"MEDIA_BLOCKED_NO_METADATA_ENDUP_NO_AUDIO_TRACK" records how many media which was blocked because it hadn't loaded metadata and ended up for being no audio track.
By collecting those data, we can know the proportion of media which should be autoplay but was blocked because of lacking metadata.
Differential Revision: https://phabricator.services.mozilla.com/D3671
--HG--
extra : moz-landing-system : lando
This prevents XBL binding from being attached, and create the Shadow Root to
host controls to be created by the script.
Shadow Root and the JS controls are lazily constructed when the controls
attribute is set.
Set nsVideoFrame as dynamic-leaf so it will ignore content child frames when
the controls are XBL anonymous content, and handles child frames from controls
in the Shadow DOM. The content nodes are still ignored since there is no
<slot>s in our Shadow DOM.
MozReview-Commit-ID: 3hk41iMa07n
--HG--
extra : rebase_source : f6f8a3facc9d83f5626cf5f3b4e3fa27438a8a8f
Use new telemetry histogram ID 'AUDIO_TRACK_SILENCE_PROPORTION' to know the proportion of
silent part in the whole audio track.
Differential Revision: https://phabricator.services.mozilla.com/D3066
--HG--
extra : moz-landing-system : lando
Since sed on multiple lines ended up being such a pain and I didn't end up
writing a script for this because I didn't think it'd end up being so boring, I
may have made a couple cleanups here and there as well...
Differential Revision: https://phabricator.services.mozilla.com/D2887
--HG--
extra : moz-landing-system : lando
