MediaPlayer should use MediaSession API |
||
Issue descriptionThe Chrome OS media player uses the MediaPlayerAPI to receive media key events. This is a private extension API only used by this player. At the moment switching on media key delegation will break this. We should make sure it works before we launch.
,
Nov 2
I have no inside knowledge about this api sorry. +raymes we should investigate removing mediaGalleryPrivate.
,
Nov 9
Yes we can definitely help with adopting MediaSession :) For the pressing Play/Pause to open the app I tried this on my Pixelbook but for some reason couldn't get it to work. One option here might be when https://crrev.com/c/1330696 lands we can make ash::MediaController only send the keyboard commands to the Media Session service if there is an active session. If not, we could have ash launch the audio player. |
||
►
Sign in to add a comment |
||
Comment 1 by tapted@chromium.org
, Nov 1Thanks for filing this! tl'dr I'm pretty sure we can just delete the mediaPlayerPrivate API... (+benwells in case my understanding is incorrect, or you know of anything that actually uses this extension API :/). The MediaPlayerAPI is actually a bit of a curiosity. There are 3 apps declaring the permission in their manifest. i.e. - ui/file_manager/{audio_player,video_player,file_manager}/manifest.json But only the video player seems to be *using* the permission, via ui/file_manager/video_player/js/media_controls.js: chrome.mediaPlayerPrivate.onTogglePlayState.addListener(..) And I'm pretty sure that's not ever actually called. chrome.mediaPlayerPrivate listeners need to be installed on the background/event page of the extension, not the app window. And there's actually a broken experience in the video player currently :(. On my pixelbook, the play/pause key simultaneously pauses AND un-pauses the video (71.0.3578.21). I'm not sure whether or not this is a regression. It _doesn't_ happen in tablet mode, so I think the RenderWidgetHost's EventFilter is seeing the keypress and passing it to the <video>, but *not* marking it handled, so it is then dispatched as keydown for 'MediaPlayPause' and handled again. (In tablet mode, the app list forces the event to be handled as an accelerator, so it's not dispatched via keydown). I was planning to fix this brokenness by fixing these apps to use mediaPlayerPrivate properly (e.g. that's what https://chromium-review.googlesource.com/c/chromium/src/+/1312439/1/ui/file_manager/audio_player/js/background.js would do). But there's no rush.. I think mediaPlayerPrivate has never been used correctly. If we can instead rely on MediaSessions, that would be neat :). But I might need your help with that. There is one caveat: mediaPlayerPrivate works on lazy background pages -- the app does not need to be running at all in order to receive the event. E.g. pressing Play/Pause on a pixelbook could [and should] _start_ the audio player if no MediaSession handles the keypress. I suspect the MediaSession API won't support this. An alternative may be to hook into the chrome.commands API and register a handler for MediaPlayPause as an extension shortcut, but I'm not sure how to ensure the event is not handled both as a shortcut and as a MediaSession command.