When autoplay media gets blocked, dispatch `MozNoControlsBlockedVideo` event to video control in order to show `click-to-play` icon.
Differential Revision: https://phabricator.services.mozilla.com/D97505
Make it a synced field on the top browsing context. This handling the
propagation right and is much simpler.
This should fix cases where we don't look at the top level docshell to
figure out if we should suspend media.
Differential Revision: https://phabricator.services.mozilla.com/D94878
Add some logs that can help us to check how many cache-streams are
suspended and the working status in `MediaCache::Update`
Differential Revision: https://phabricator.services.mozilla.com/D92124
YouTube frequently uses the same <video> element for sequential videos and ads. We want to record telemetry if any of these were non-empty, not only consider the last one played when the tab is closed.
Differential Revision: https://phabricator.services.mozilla.com/D88098
We don't need `autoplay_would_be_allowed_count` and `autoplay_would_not_be_allowed_count`, so we can remove all related codes.
Differential Revision: https://phabricator.services.mozilla.com/D83227
We would like to remove `page_had_media_count` and use a new probe `in_page_count` to record the total number of top level content documents using media.
Therefore, we would rename WindowContext's `DocTreeHadAudibleMedia` to `DocTreeHadMedia` in order to support the new usage.
In the future, if we want to know something like "the percentage of media element is being used for MSE/EME?", then this scalar can be the base and used to calculate the answser.
Differential Revision: https://phabricator.services.mozilla.com/D83225
Removes
- MEDIACACHESTREAM_LENGTH_KB
- MEDIA_PLAY_PROMISE_RESOLUTION
- AUDIO_TRACK_SILENCE_PROPORTION
and all the code I could find that was specific to reporting these values via
telemetry.
Differential Revision: https://phabricator.services.mozilla.com/D88868
Add 3 probes
- Play time for encrypted elements.
- Play time for Clearkey elements.
- Play time for Widevine elements.
Differential Revision: https://phabricator.services.mozilla.com/D88895
"Manager" is vague, and it seems to mostly keep some members around rather than
managing them. Port is analogue to MediaInputPort in that it acts as a link
between two tracks. Neither type of port does very much heavy lifting -- they
are similarly dumb.
Differential Revision: https://phabricator.services.mozilla.com/D88812
This re-uses MediaStreamRenderer to render video into a secondary container, to
get identical logic for the clone target as for the clone source. The
MediaStreamRenderer can handle audio, currentTime and more as well, but those
are not used here.
Differential Revision: https://phabricator.services.mozilla.com/D87139
The first-frame output used to only be applied when not rendering the
MediaStream, and the regular video output was applied when rendering.
The difference with this patch is when rendering -- both the first-frame and the
regular outputs are applied at the same time. The former allows one frame to go
through to the VideoFrameContainer, then the regular output takes over and lets
any frames through. Nothing in how frames are rendered should be noticable by
users.
This allows for simpler logic for resolving the visual clone target promise in a
future patch, as we won't have to track the first frame in different outputs
depending on the rendering state.
Differential Revision: https://phabricator.services.mozilla.com/D87138
This allows different users of renderers to inject different first frame
outputs. So far there is only one, but a future patch will bring a special one
for the secondary video frame container.
Differential Revision: https://phabricator.services.mozilla.com/D87137
I have observed async calls to the MediaStreamRenderer's mWatchManager::Unwatch()
in flight after it was Shutdown(). This would cause an assertion failure in
debug. Per the comment we should do the same in Unlink as
EndSrcMediaStreamPlayback() without creating new strong refs. This conforms to
that instruction.
I am not willing to null out the other members at this point, since at least
HTMLVideoElement's relies on the selected video track to exist in some cases.
Differential Revision: https://phabricator.services.mozilla.com/D87136
This allows the FirstFrameListener to be instantiated outside of
HTMLMediaElement. A future patch brings in a subclass in HTMLVideoElement.
This also renames FirstFrameListener to FirstFrameVideoOutput since that better
denotes what it is.
Differential Revision: https://phabricator.services.mozilla.com/D87135
This unclutters HTMLMediaElement somewhat by putting away the logic for handling
the FirstFrameListener into MediaStreamRenderer, which is better suited for the
task.
This will allow us to use a second MediaStreamRenderer to properly track video
tracks for a secondary VideoFrameContainer.
Differential Revision: https://phabricator.services.mozilla.com/D87134
When a media without src or with error enters fullscreen or PIP mode, we don't want to control it. Therefore, we shouldn't start the listener for it.
In addition, updating PIP/fullscreen state no matter the listener starts or not. See following example.
1. Play a media and it enter PIP/fullscreen (it would update `state=true`)
2. abort the current src (that would stop the listener)
3. leave PIP/fullscreen (in this case, we don't have src, so the listener won't start, but we still need to update the `state` to `false`)
Differential Revision: https://phabricator.services.mozilla.com/D85785
Calling `NotifyMediaFullScreenState()` is related with updating state on media controller, which is only used for media element. So it'd be better to move that into media element.
Differential Revision: https://phabricator.services.mozilla.com/D85513
In bug1654045, we would stop controlling media once media reaches to the end. Considering some user might still want to control media by pressing media keys even if it has ended, so adding a pref to control this abilitiy.
Differential Revision: https://phabricator.services.mozilla.com/D85930
Our current implementation is to allow to resume media by using media key after media reaches the the end. However, we don't know how many users would really use media key like that, and if they don't use media key in this way.
The benefit to use that approach are (1) being able to give media key controllability back to other applications which are really playing media (2) to avoid possible compatibility issue (Chrome has been using this approach as well)
Differential Revision: https://phabricator.services.mozilla.com/D85228
We want to modify our current behavior from "resuming all media" to "resuming latest paused media" when pressing `play` media key.
The reason of doing that is because that give us better user experience, espeically on Facebook. Chrome has been taking this approach, so we want to follow this strategy. The test in D84879 can help to understand this scenario.
Differential Revision: https://phabricator.services.mozilla.com/D85118
Currently, we treat `pause` and `stop` equally, but `stop` is actully implying more meaning, which should stop controlling media entirely. Therefore, we would pause media and stop controlling it when receiving `stop`.
In addition, removing pause state checking, because it wouldn't happen anything to call `play()` and `pause()` if media is already playing or paused.
Differential Revision: https://phabricator.services.mozilla.com/D84875
This changes the UA widget setup (again). What is going on in this
test-case is that we have a marquee inside a video, two things that have
their own UA widget. Given how the code is currently written, the
runnable to attach and set up the marquee's widget is posted before than
the video one (which is potentially reasonable).
However that means that the marquee one runs before and flushes layout,
and catches the video in an inconsistent state (in the composed doc, but
without a shadow root). That in turn messes up reflow because
nsVideoFrame assumes stuff.
Rather than putting the attach / detach logic in script runners, just
run that bit synchronously, and post only the event async. I audited the
consumers of those events and it seems fine to me, they either already
deal with the possibility of the shadow root being already detached or
they don't care.
For teardown, none of the destructors of the UA widgets rely on the
shadow root being still attached to the element.
Differential Revision: https://phabricator.services.mozilla.com/D84487
When a media enters PIP mode, we should consider it as an important one which user might want to control. Therefore, start the listener in order to notify the media has been started, then we would update the PIP state [1] which would activate the controller.
As the PIP state changes can happen after `Stop()` is called, so in this patch, we would remove the start check and reset `mControlAgent` in `Stop()` in order to update PIP state after the listener stops. Eg. Reset the PIP video's src, then cancel the PIP.
[1] https://searchfox.org/mozilla-central/rev/9b282b34b5aa0f836beb735656c55efb2cc4c617/dom/html/HTMLMediaElement.cpp#7902
Differential Revision: https://phabricator.services.mozilla.com/D84119
In D73335, we remove those check which causes a regression where inaudible media is also able to be controlled by media control keys.
In order not to control those inaudible media, we should add the check back. If the media is inaudible, then we should not start the listener that would connect media element to the media control.
In addition, I also found that starting the listener for inaudible media would make the media controller's playback state incorrect, because the playback state is calculated by all controlled media. If an inaudible media is playing, the playback state should not consider that media.
Differential Revision: https://phabricator.services.mozilla.com/D84115
It seems no much benefit to create `MediaControlKeyListener` lazily, we should create it in the start and destroy it in the end so that we don't need to check if `mMediaControlKeyListener` exists or not when we want to check if the listener starts.
Differential Revision: https://phabricator.services.mozilla.com/D84116
`NotifyMediaControlPlaybackStateChanged()` would be called when `mPaused` changes, but it would only take effect after the listener starts. If the media changes its `mPaused` before we starts listener, then we have to manully update `NotifyMediaControlPlaybackStateChanged()`.
However, I think wrapping this detail into `Start()` itself would be clearer.
Differential Revision: https://phabricator.services.mozilla.com/D84649
The reason of checking those conditions before calling `StartListeningMediaControlKeyIfNeeded()` is because we was only starting the listener after media starts, which has been modified in D79234. Now we would start the listener before media starts, so we can remove that check.
Differential Revision: https://phabricator.services.mozilla.com/D84114
