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?

[martinthomson]

@jamiewalch, I know that this is potentially a little more inconvenient, but a full-screen game could intercept Alt-Tab and relinquish full-screen access if they wanted to specifically enable that use case. What I'm most concerned about is the potential for selective key interception to be very confusing, so that the exit criteria are not always obvious.

[martinthomson]

@xingri, that's a question that I don't think we can answer until we get to implementation.

[xingri]

@martinthomson , @marcoscaceres

I have evaluated the current keyboard lock interface and found that it should be working with the preventDefault call.
As following test codes.

Do both of you think it's ok to madate adding the steps of calling "preventDefault()" in case of the keys which need to be locked by the application? Which was not required by the https://wicg.github.io/keyboard-lock/ spec.

// For browser(enum) from the FullscreenKeyboardLock { "none", "browser", "system" };
document.addEventListener("keydown", (e) => {
if ( lock &&
(e.code === "Escape" ||
((e.code === "KeyN" || e.code === "KeyT" || e.code == "KeyP"
|| e.code == "KeyW" || e.code == "KeyQ" ) &&
(event.ctrlKey || event.metaKey)))
) {
// handling events.
e.preventDefault();
}
});

[jamiewalch]

This might work for keys that would otherwise be handled by the browser (so the ones in your example would all work, I think), but it's not sufficient for system keys like Alt+Tab. These have to be intercepted (or not) at the OS level, and at least on some OSes (Windows and X11 Linux for sure) this needs to be synchronous, so you can't defer the decision to the web page.

[xingri]

@jamiewalch Thank you so much for the prompt response. I forgot to mention that the above test code was for the browser (enum) use cases.
We will consider the system (enum) use case as well.