Each platform has different ways to allow users to use media control, adding a telemetry probe to detect that would be good for us to know the usage among different platforms.
Differential Revision: https://phabricator.services.mozilla.com/D93282
Each platform has different ways to allow users to use media control, adding a telemetry probe to detect that would be good for us to know the usage among different platforms.
Differential Revision: https://phabricator.services.mozilla.com/D93282
The old way to open/close the event source, which is triggered by controller amount change event, is less intuitive, and we do the extra clean up when close the event source by assigning some parameters [1] that causes an issue on Windows where the control interface can't be clear up completely.
Each platform has its own way to clean the interface. For example, on Windows, we can simply call `ISystemMediaTransportControlsDisplayUpdater::ClearAll()`. So calling those functions actually helps nothing. The best way to do that is to ask the event source to do the clean up, rathering than setting those unnecessary parameters.
Therefore, we make it happen closer to when we determine or clear main controller and ask the event source to take a responsible to clean up when it closes.
[1] https://searchfox.org/mozilla-central/rev/35245411b9e8a911fe3f5adb0632c3394f8b4ccb/dom/media/mediacontrol/MediaControlService.cpp#410-413
Differential Revision: https://phabricator.services.mozilla.com/D92115
The old way to open/close the event source, which is triggered by controller amount change event, is less intuitive, and we do the extra clean up when close the event source by assigning some parameters [1] that causes an issue on Windows where the control interface can't be clear up completely.
Each platform has its own way to clean the interface. For example, on Windows, we can simply call `ISystemMediaTransportControlsDisplayUpdater::ClearAll()`. So calling those functions actually helps nothing. The best way to do that is to ask the event source to do the clean up, rathering than setting those unnecessary parameters.
Therefore, we make it happen closer to when we determine or clear main controller and ask the event source to take a responsible to clean up when it closes.
[1] https://searchfox.org/mozilla-central/rev/35245411b9e8a911fe3f5adb0632c3394f8b4ccb/dom/media/mediacontrol/MediaControlService.cpp#410-413
Differential Revision: https://phabricator.services.mozilla.com/D92115
Create a new namespace `MediaControlService` to use those helper functions which is used to get the main controller related status.
Then, move those functions from `ChromeUtils` to `MediaControlService`, which give us two benefit. The first is that we can remove redudant test-only enum `MediaSessionPlaybackTestState`, the second is a pref-required work for bug1656398, to fix the build order error when exposing `MediaSessionPlaybackState` in the media controller's webidl.
Differential Revision: https://phabricator.services.mozilla.com/D86620
Rename `NotifyControllerBeingUsedInPictureInPictureMode()` to `RequestUpdateMainController()` and call that method when a controller enters fullscreen.
Differential Revision: https://phabricator.services.mozilla.com/D85517
Treat media controller being used in fullscreen as same as the one being used in PIP mode, so it won't be replaced by other normal controller if it's already a main controller.
Comparing with a normal controller, a controller being used in PIP/fullscreen should have a higher priority to become a main controller.
In addition, renaming `IsMediaBeingUsedInPIPModeOrFullScreen()` to `IsBeingUsedInPIPModeOrFullscreen()`.
Differential Revision: https://phabricator.services.mozilla.com/D85514
What this patch do are
- to add `SetPositionState()` on `MediaControlKeySource`
- notify `MediaControlKeySource` when the main controller's position state changes
The advantage of doing so is
- to allow `MediaControlKeySource` to know the position state change so that it can update the display content (eg. showing the duration or the progress bar of playback)
Differential Revision: https://phabricator.services.mozilla.com/D80789
This patch would
- introduce new methods `SetEnableFullScreen()` and `SetEnablePictureInPictureMode()` on `MediaControlKeySource`
- notify the change of enabling/disabling the fullscreen and picture-in-picture mode to `MediaControlKeySource`
The advantage of doing this is
- to allow the key source to do corresponding operations when media enters/leaves the fullscreen/picture-in-picture
eg. GeckoView would use them to implement its API, `onFullscreen()` and `onPictureInPicture()`
Differential Revision: https://phabricator.services.mozilla.com/D79785
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
This patch will
- create a chrome-only webdil interface `MediaController`
- expose supported keys via `MediaController` webidl interface
The advantage of doing so are
- to have a dedicated interface that is only used for MediaController that can be used for testing and our future plan (media hub)
More Details :
Currently, we access media controller's from `ChromeUtils` [1], but it causes a problem of creating a duplicated enum of the enum which we want to expose into Chrome JS.
Instead, we should create a media controller interface to access all its attibutes, which is more easier and clean.
In addition, we're planning to have a something like Chrome's media hub [2]. In order to do that, we have to expose some JS methods to allow us to control playback directly from Chrome JS.
[1] https://searchfox.org/mozilla-central/rev/559b25eb41c1cbffcb90a34e008b8288312fcd25/dom/chrome-webidl/ChromeUtils.webidl#485-493
[2] https://blog.google/products/chrome/manage-audio-and-video-in-chrome/
Differential Revision: https://phabricator.services.mozilla.com/D77757
This patch will
- add a method `SetSupportedMediaKeys()` on `MediaControlKeysEventSource`
- set main controller's supported key to the event source
The advantage of doing so are
- to allow the event source knowing which key is supported in order to determine the displayed UI button
Differential Revision: https://phabricator.services.mozilla.com/D77200
We would like to ensure that the controller being used in Picture-in-Picture mode can always be the main controller, which means even if there are other controllers starting later than PIP video, they are not able to become the main controller, but we would still maintain a correct order of controllers that can ensure that the main controller can be selected correctly after current main controller get destroyed.
For example, we have a list `[A, B, C]` and `C` is the main controller. And `D` is new coming controller, then the list would become `[A, B, D, C]` and `C` is still the main controller. But if `C` gets destroyed, the list would become `[A, B, D]` and `D` is the main controller.
Differential Revision: https://phabricator.services.mozilla.com/D67710
--HG--
extra : moz-landing-system : lando
The main controller is the only controller that can receive media control keys among all other controllers registered to the service, and it should always be the last controller which is playing.
Therefore, we would maintain a list which sorts the controllers based on the order of playing controller, and the last one (last playing controller) would be the main controller.
For example, if the controller A starts first, then B starts, B should be the main controller. But if A restarts later then A should become the main controler again.
Differential Revision: https://phabricator.services.mozilla.com/D66857
--HG--
extra : moz-landing-system : lando
When we remove a controller from the list of controllers, which is a `nsTarray`, the array needs to be reconstructed if the removed controller is not the first or last element of the array.
Eg. If we have a list of controllers, [A, B, C, ....., Z] and in some situation we would like to reoroder it to [A, C, D, ......, Z, B]. If we use nsTArray, then doing this kinds of reorder is expensive because it can't arbitrarily move the element back and forth, but the linked list can.
So we replace the `nsTArray` with `LinkedList`, then this operation would become `O(1)` which could improve the performance
Differential Revision: https://phabricator.services.mozilla.com/D66855
--HG--
extra : moz-landing-system : lando
Implement a chrome-only method `getCurrentMediaSessionPlaybackState()` to expose current actual playback state in testing.
The reason we create an new enum `MediaSessionPlaybackTestState` is because of building issue. If we use `MediaSessionPlaybackState` directly in the `ChromeUtils.webidl`, then the codegen would automatically add an header include of `MediaSessionBinding.h` in the `ChromeUtilsBinding.h`, which would cause the complier complaining about lots of undeclared identifier.
Differential Revision: https://phabricator.services.mozilla.com/D66344
--HG--
extra : moz-landing-system : lando
`PlaybackState` and `MediaSessionPlaybackState` are actually quite similar, and we don't want to have to many states to confuse reader and do unnecessary tranform between two states. Therefore, replaceing `PlaybackState` with `MediaSessionPlaybackState`.
Differential Revision: https://phabricator.services.mozilla.com/D66342
--HG--
extra : moz-landing-system : lando
Create a chrome-only method to get the current media metadata to know if we correctly update the media metadata or not. That method would only be used for testing.
Differential Revision: https://phabricator.services.mozilla.com/D64849
--HG--
extra : moz-landing-system : lando
Whenever the main controller updates its metadata, we should also notify the event source to update the metadata, because we don't want to show the wrong metadata on the virtual control interface.
In this patch, we add a new media event to notify this situation and create a new method `SetMediaMetadata()` on the `MediaControlKeysEventSource`. But we leave that function empty for now, and will have follow-up bugs to handle setting metadata on each different platforms.
Differential Revision: https://phabricator.services.mozilla.com/D64847
--HG--
extra : moz-landing-system : lando
We should ensure that controllers has been removed from the service when it destroys. Therefore, we remove the assertion in `MediaControlService::RegisterActiveMediaController()` and `MediaControlService::UnregisterActiveMediaController()`, and return the result to allow caller to know if it has been registered or unregistered or not in order to do error handling or add assertions.
Differential Revision: https://phabricator.services.mozilla.com/D59286
--HG--
extra : moz-landing-system : lando
As each media controller corresponds to a tab (a browsing context tree), so the controller's life cycle should be equal to the tab. Currently we use the top-level browsing context to represent a tab, so when that browsing context is being destroyed, we should also destroy the corresponding media controller.
Therefore, `MediaControlService` don't need to have methods to access media controller anymore, we should access media controller directly from the top-level canonical browsing context.
Differential Revision: https://phabricator.services.mozilla.com/D58591
--HG--
extra : moz-landing-system : lando
To modify variable and function names to emphasize all media controllers added in the service are active controllers. If the controller doesn't have any controlled media, they won't be added into the service.
Differential Revision: https://phabricator.services.mozilla.com/D58589
--HG--
extra : moz-landing-system : lando
Based on the main controller's play state to set the correct playback state to the event source.
Differential Revision: https://phabricator.services.mozilla.com/D58261
--HG--
extra : moz-landing-system : lando
Implement a class `ControllerManager` to wrap the details of how to select the main controller, which would also be used to monitor main controller's play state change.
Differential Revision: https://phabricator.services.mozilla.com/D58260
--HG--
extra : moz-landing-system : lando
We have no plan to use those functions, so remove them in order to keep code clean.
Differential Revision: https://phabricator.services.mozilla.com/D58172
--HG--
extra : moz-landing-system : lando
When a function returning a pointer, returning a raw pointer is enough. The callers should use `RefPtr` to store this pointer explicitly if they do need to add a refcounting.
In addition, using `RefPtr` in the parameter cannot prevent anything as well.
Differential Revision: https://phabricator.services.mozilla.com/D58171
--HG--
extra : moz-landing-system : lando
We have no plan to use those functions, so remove them in order to keep code clean.
Differential Revision: https://phabricator.services.mozilla.com/D58172
--HG--
extra : moz-landing-system : lando
When a function returning a pointer, returning a raw pointer is enough. The callers should use `RefPtr` to store this pointer explicitly if they do need to add a refcounting.
In addition, using `RefPtr` in the parameter cannot prevent anything as well.
Differential Revision: https://phabricator.services.mozilla.com/D58171
--HG--
extra : moz-landing-system : lando
The event source in `MediaControlKeysManager` now is created dynamically, so that means sometime we don't have an event source to allow people add or remove listener
Therefore, make `MediaControlKeysManager` inherit from `MediaControlKeysEventSource` to allow it to provide add/remove listener methods and inherit from `MediaControlKeysEventListener` to allow it to monitor the real media control keys event and dispatch event to its listeners.
Differential Revision: https://phabricator.services.mozilla.com/D51766
--HG--
extra : moz-landing-system : lando
In this patch, we dynamically create or destroy media keys event source according to the amount of media controller .
We would create the event source when we have a controller which needs to be controlled, and destory the event source when there is no controllers existing.
In addition, create a `Init()` function for media service for calling any other owned module's initialization, which is used to ensure that we finish setting the `gMediaControlService` before any other classes call `MediaControlService::GetService()`.
Differential Revision: https://phabricator.services.mozilla.com/D51765
--HG--
extra : moz-landing-system : lando
As we have a need to know if there is any existing controller needs to be controlled in order to achieve dynamically creation and destruction of media keys event source. (that will be implemented in patch2)
Therefore, using the media event to send the current media controller amount when the total media controller amount changed in the media service.
Differential Revision: https://phabricator.services.mozilla.com/D51763
--HG--
extra : moz-landing-system : lando
Create methods to add or remove listener directly to the media control keys event source.
So if anyone has a need to monitor media control keys event, they can simply implement their own listener and use `MediaControlService::GetMediaControlKeysManager()` to add or remove a listener.
Differential Revision: https://phabricator.services.mozilla.com/D50687
--HG--
extra : moz-landing-system : lando
Create methods to add or remove listener directly to the media control keys event source.
So if anyone has a need to monitor media control keys event, they can simply implement their own listener and use `MediaControlService::GetMediaControlKeysManager()` to add or remove a listener.
Differential Revision: https://phabricator.services.mozilla.com/D50687
--HG--
extra : moz-landing-system : lando
File's name should reflect what the class is inside the file.
Differential Revision: https://phabricator.services.mozilla.com/D50682
--HG--
rename : dom/media/mediacontrol/MediaHardwareKeysEvent.cpp => dom/media/mediacontrol/MediaControlKeysEvent.cpp
rename : dom/media/mediacontrol/MediaHardwareKeysEvent.h => dom/media/mediacontrol/MediaControlKeysEvent.h
rename : dom/media/mediacontrol/MediaHardwareKeysManager.cpp => dom/media/mediacontrol/MediaControlKeysManager.cpp
rename : dom/media/mediacontrol/MediaHardwareKeysManager.h => dom/media/mediacontrol/MediaControlKeysManager.h
extra : moz-landing-system : lando