-
Notifications
You must be signed in to change notification settings - Fork 30
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Why can't keyboard events be used here? #21
Comments
What are the keyboard events? I tested this yesterday, and on a Mac no events are delivered when pressing these buttons. Also, on what object should those key events be dispatched? Having them on the document would require some page-provided framework to delegate if there are multiple components which can play audio. Android's MediaSession is documented as "In general an app only needs one session for all playback, though multiple sessions can be created to provide finer grain controls of media." Allowing the same in a Web API seems like a good starting point. Finally, there's the "Double tap and other key sequences may follow platform-specific conventions" bit in the README. |
On the element that has focus. The bit we're missing is a way to lock specific keys (the media ones) to a particular element. If an However, the developer could add listeners, prevent the default & do their own thing. Allowing an arbitrary element to get a global focus for these events means it can be used for playback driven by SVG, Web Audio, Canvas, Web Animation etc etc.
I think platform defaults are fine but developers should be able to prevent default and do their own thing. Extensible web & all that. |
Thanks @annevk! I find the string "MediaPlayPause" in Blink so presumably there is a platform where it works, probably Windows. If there are sites (YouTube?) using these key events then we have a bit of a problem, in particular if it's the MediaTrackNext/MediaTrackPrevious keys where we couldn't just implement default behavior to do the right thing and stop firing the events. Android has events delivered via RemoteControlClient or MediaSession: Note the inclusion of both KEYCODE_MEDIA_FAST_FORWARD and KEYCODE_MEDIA_NEXT, as well as e.g. stuff related to rating. iOS has MPRemoteCommandCenter: Most of the commands fall outside the existing key events. That doesn't mean we can't add key events, of course. |
Hi @jakearchibald!
This sounds interesting, can you submit the proposal for Element-based audio focus so that we can take a look? (You didn't mention audio focus, but I assume there's some connection.)
Absolutely, not making this work would amount to a complete failure. It's even the first use case mentioned in the README: "While watching a video or listening to audio in the background, pause and resume playback using the play/pause key." There are many ways to achieve this modest goal of course. MediaRemoteControl has a |
Basic usageEven if the device is incapable or unwilling to grant media focus, you want the keys to work when the page is focused: var audioElement = document.querySelector('audio.music');
document.addEventListener('keyup', event => {
switch (event.key) {
case "MediaTrackNext":
event.preventDefault(); // etc etc
break;
case "MediaTrackPrevious":
event.preventDefault(); // etc etc
break;
case "MediaPlayPause":
event.preventDefault(); // etc etc
break;
}
}); To request media focus: audioElement.requestMediaFocus(); If the focus is granted, the media keys will be dispatched from
Question: Should Controlling media focus
element.requestMediaFocus().then(function(mediaFocusController) {
// To set metadata
mediaFocusController.setDetails({
poster: mediaImage,
title: "Song title",
duration: durationInMs
});
// Listen for loss of focus:
mediaFocusController.addEventListener('released', func);
// To release focus:
mediaFocusController.release();
}, function() {
// Focus denied
}); The user agent may infer details from the element until Key defaults & automatic media focusPressing A UA may choose to assign media focus to an element automatically. Eg, if a mobile user plays video/audio on a page, then locks the screen, the UA could media-focus the playing element. The default key events come into play, as does the default detail detection. This plays well with |
(btw |
Thanks Jake, that's interesting, and it points to a use case that isn't listed in the README, something like "If nothing on the system has media focus, such that pressing the hardware media keys would have no effect, allow the foreground app/tab to respond to those keys, e.g. to begin playback." Does that sound right? In the One could also make audio focus and key events entirely orthogonal concepts, but I think that would lead to some pretty strange behavior as seen from a user. Sorting out #9 would go a long way towards figuring out the basic design. (There's also the question of how you get a |
Yeah, otherwise the media session spec will break the media parts of the keyboard events spec, even if there isn't an active media session. |
Is it possible to implement that behavior on Android? The documentation says "To receive commands, media keys, and other events a I haven't tried it, but my guess is that doing that would prevent other applications from receiving media button events. However, if the key events are delivered like any other key events when there is no app currently handling them, that would work. If the only concern here is existing Web apps, we could of course simply continue to delivering those events when nothing has audio focus, on desktop browsers only. It's not required for compat to use these key events in the new model, if it turns out to be a bad fit. How should things like |
Oh, if an element in another app/window has media focus, I'd expect only the media-focused element to receive media key events, as if it had a lock on those.
Also duplication of listeners. If I'm denied media focus, I should still be able to use the same key events while the window has focus (as long as nothing else on the system has focus).
They don't feel like keys to me, particularly seeking. It'd be great if that could follow the event model of |
We'll have to verify how this actually works on Android. I'd be unsurprised if it isn't exactly what would be needed to make the use case work.
This bit I don't understand, should it be possible to be denied audio focus if there is nothing else playing? Can this happen on any native platform?
In other words, a simple event named |
8b23f34 doesn't use keyboard events, please review. |
Functionality has been moved to https://mediasession.spec.whatwg.org/#media-remote-controls. |
Leaving this to @jakearchibald. |
Was there a reason for not using keyboard events for these events triggered by keys? The current proposal loses us *up *down events, and event delegation. |
Where would keyboard events be fired, on the active I'm not entirely certain, but it doesn't look like there are *up and *down events at the Android level for media keys, whether it's the button on the headphone cord or soft keys in a notification. That being said, on the desktop platforms that currently do fire Other ideas? |
On the document.addEventListener('keyup', event => {
switch (event.key) {
case "MediaPlayPause":
if (!(event.target instanceof HTMLMediaElement)) {
// just return, let the default do its thing
// (the default would be play/pause)
return;
}
event.preventDefault();
document.querySelector('.first-item-in-playlist').play();
break;
// …
}
}); The above event would handle events that have been targeted to a particular
That's a shame, but I don't think we should limit the web's spec by what the current version of Android does. Of course, the spec should suggest what happens on inputs that do not have up/down support. |
A media session can have more than one participating media element, and eventually likely also Web Audio's |
Hmm, yeah, it shouldn't fire on multiple elements at once. I guess, even though this a key-triggered system, keyboard events don't fit. I guess developers will have to add listeners for both media keys, and media session events. |
Before we implement or ship any events on |
There are a few open issues around remote controls: w3c#11 w3c#21 w3c#42 w3c#45 w3c#56 In particular issue 45 will change this API a lot, so in order to not tempt implementors into going with this design, remove it for now. Much of this, in particular the prose and example, can be revived once we have the time to hammer out the flattened API design.
The approach now is that the browser might want to handle some keys. Either virtual or physical and fire the right I believe this is resolved. Please reopen if you disagree. |
It seems the only special bit is about receiving them while not in focus. Anything else? @jakearchibald
The text was updated successfully, but these errors were encountered: