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
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
The telemetry probe, which is related with `mDocTreeHadPlayRevoked`, has already been removed, so we don't need these code anymore.
Differential Revision: https://phabricator.services.mozilla.com/D83163
Whenever the audible state changes, we should always store the latest state but only notify the change after playing starts.
Differential Revision: https://phabricator.services.mozilla.com/D83549
The MediaStreamRenderer handles the AudioOutput of an HTMLMediaElement. it register/unregister the AudioOutput according to the rendering status. The sink-change follows the logic of AudioOutput thus it has been moved in it.
The previous way created an error when the element had been muted and the sink had been changed before the source MediaStream was attached to the element. The error occured because it was possible, the same entry to be registered more than once in the AudioOutput's list, which resulted in the track to be unmuted when it should not.
Differential Revision: https://phabricator.services.mozilla.com/D82529
When aborting the current load, media element is undoubtedly inaudible. Therefore, we should reset its audible state in order to keep the audible state correct. That can help us show the sound indicator on the tab bar correctly.
Differential Revision: https://phabricator.services.mozilla.com/D81631
At the end of `HTMLMediaElement::SetSrcMediaStreamSink` a redirection of MozPromises, from `GenericPromise::AllPromiseType` to `GenericPromise` is taking place. However, this is not necessary since this is an internal method and the returned value of the promise is not useful. Thus the `GenericPromise::AllPromiseType` can be returned directly and avoid the extra thread dispatch.
Differential Revision: https://phabricator.services.mozilla.com/D80908
This patch would
- build the relationship between a media element and the media controller when media finishes loading, instead of building that after starting playing media
The advantage of doing this is
- the prework of being able to control media before media starts playing
Differential Revision: https://phabricator.services.mozilla.com/D79234
This patch would
- move the mechanism of creating a stop timer from media element to media controller
The advantage of doing this is
- to remove redundant timers in the content process, because we only need to maintain one global timer for a whole tab
Differential Revision: https://phabricator.services.mozilla.com/D79233
Before P1, GetCurrentThreadSerialEventTarget would have always returned the same data as NS_GetCurrentThread, making the comment incorrect Now it will properly return the running TaskQueue if any.
This change of name more clearly exposes what they are doing, as we aren't always dealing with threads directly; but a nsISerialEventTarget
Differential Revision: https://phabricator.services.mozilla.com/D80354
The SetSinkId method of HTMLMediaElement has been enhanced to handle the sink change when the element is sourced with a MediaObject through the srcObject attribute. It makes use in the corresponding method of AudioStreamTrack taking into account the AudioOutput and Volume that has to be removed and re-added to the right track.
Differential Revision: https://phabricator.services.mozilla.com/D77809
This patch will
- remove `MediaControlKeysEvent` and use `MediaControlKey` to replace it
- rename names for all `MediaControlKey` related methods, functions, classes and descriptions
The advantage of doing so are
- remove the duplicated type so that we only need to maintain `MediaControlKey`
Differential Revision: https://phabricator.services.mozilla.com/D78140
