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
"blocked" event is used for blocking autoplay. The `AudioChannelAgentBlockedPlay()` returns true when we lost audio focus on Android, so actually we don't need to dispatch "blocked" event.
Differential Revision: https://phabricator.services.mozilla.com/D18627
This patch removes the XBL videocontrols binding and make <video>
to always use the UA Widget to generate controls.
DevTools tests that look for NAC is switched to use <input type=file>.
Differential Revision: https://phabricator.services.mozilla.com/D17571
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
This can legitimately happen while paused since the watchmanager calling this
is dispatching the calls. As such they're out of sync with the paused state,
and we need to allow updating the time while paused.
FireTimeUpdate does ignore the call if the time hasn't actually been updated,
so the only impact from this is that we could do a lot of unnecessary
dispatching while paused without noticing.
Differential Revision: https://phabricator.services.mozilla.com/D15731
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
This event is used to notify tab that this site is blocked and we should show the blocking icon for it. Patch2 will handle following details.
Differential Revision: https://phabricator.services.mozilla.com/D14794
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 event is used to notify tab that this site is permanently blocked and we should show the blocking icon for it. Patch2 will handle following details.
Differential Revision: https://phabricator.services.mozilla.com/D14794
This patch moves all UA Widget calls to helper functions in Element.cpp. The helper function AttachAndSetUAShadowRoot sets the shadow root in a runnable, so that it is in the same order of NotifyUAWidget* runnables.
Differential Revision: https://phabricator.services.mozilla.com/D13479
Due to the state watcher logic, mirror tasks can be dispatched while in stable state. We must not have visible aJS change during such stable state.
Differential Revision: https://phabricator.services.mozilla.com/D12699
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
HasVideo() might be false even though there is a video track present as it will
only look at the resolution of a VideoTrack.
Differential Revision: https://phabricator.services.mozilla.com/D9103
Should the media element be cycle collected and a decoder still be active, a change of state could have caused the track list to be re-created causing a cycle between the HTMLMediaElement and the track list.
We also check when potentially updating the ready state if the self reference is still needed.
Place various assertions.
Differential Revision: https://phabricator.services.mozilla.com/D11860
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
We were clamping the playback rate properly if the decoder had been setup already, but not if setting it before playback started.
Differential Revision: https://phabricator.services.mozilla.com/D11005
There are often websites using videos without an audio track as background image or as GIF-like image. For these cases,
we don't want to hold a wakelock.
Differential Revision: https://phabricator.services.mozilla.com/D7215
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
