Keyboard lock

[martinthomson]

What problem are you trying to solve?

Fullscreen applications might want to access keys that would ordinarily break out of the full screen state. For instance, games often use the ESC key to access menus, remote desktop applications often use keyboard shortcuts for app switching. Having these actions sent to the site, rather than the local system might be desirable.

What solutions exist today?

Google previously proposed https://github.com/WICG/keyboard-lock/

How would you solve it?

I made a proposal a long time ago here: https://docs.google.com/document/d/191YzTVJRg4mIkAYCHYbDYFugO4xiLw6xE_lDuUOfItQ/edit?usp=sharing

Some of those details might change in discussion. For instance, I consider points made by others (in comments on that document) about system key lockout to be convincing.

Anything else?

I'm making this contribution here to make clear that this proposal is covered by Mozilla's commitment to the WHATWG IPR policy. My intention is not to drive this work, but am willing to support someone who wants to pursue it.

[foolip]

@martinthomson is it a fair summary to say you're suggesting a way to request fullscreen and keyboard lock at the same time?

cc https://wicg.github.io/keyboard-lock/ editors @garykac and @jamiewalch

[xingri]

@martinthomson Thank you for brining this idea back.
We are ok pursuing this approach but as Gary and Jamie already commented on the proposal,
we still want to have the options for the key codes which will give a better flexibility to the application
such as handling Alt-Tab Key.

optional sequence<DOMString> keyCodes = []

[martinthomson]

From a user perspective, I don't think that there is much value in having an indeterminate set of key codes being routed to the site. Expectations are everything here, so I would suggest that while a site might choose not to listen for certain key codes, they would have the option of intercepting any key (aside from those special sequences that the host reserves, like ctrl-alt-del on Windows).

The reason there is to avoid situations where expectations are built up about availability of certain sequences on one site, only to find that those expectations are invalid on another site.

Sites can of course not bother to listen for certain codes, as is their prerogative. But they would receive them all.

[marcoscaceres]

@martinthomson, do I have your permission to copy/paste part of the proposal as the basis for the pull request to the spec? (i.e., can I treat it also as "C0")?

[martinthomson]

You have my permission, and blessing :)

[marcoscaceres]

Thanks @martinthomson!

Ok, here's a straw person based on Mozilla's proposal:
#232

It's drafty, so feedback very much appreciated!

[jamiewalch]

Sites can of course not bother to listen for certain codes, as is their prerogative. But they would receive them all.

It's worth noting that even if a site ignores a certain key, the fact of intercepting it at the OS level changes its behaviour. The canonical example of this is a full-screen game that wants to:

• intercept the Windows key (because it's easy to hit by accident, and its default behaviour of opening the Start menu is annoying when playing the game); but
• leave Alt+Tab with its default action, because switching to a web browser to consult a walkthrough is useful.

We can't just intercept all keys and let the game ignore Alt+Tab, because then there's no way to "re-inject" it to support the second scenario. That's how we ended up with the current API design where the set of desired keys must be declared up-front.

[xingri]

@martinthomson, @marcoscaceres could you please specify the key codes could be handled by each of browser and system enum of the proposal?
And also, for the application which wants to receive both browser & system keys? What could be the syntax for it?