Keyboard Lock

[philn]

WebKittens

No response

Title of the spec

Keyboard Lock

URL to the spec

https://wicg.github.io/keyboard-lock/

URL to the spec's repository

https://github.com/wicg/keyboard-lock/

Issue Tracker URL

No response

Explainer URL

https://github.com/WICG/keyboard-lock/blob/gh-pages/explainer.md

TAG Design Review URL

No response

Mozilla standards-positions issue URL

mozilla/standards-positions#196

WebKit Bugzilla URL

No response

Radar URL

No response

Description

This spec can be useful in cloud gaming use-cases for instance. I'd like to know Apple's position about supporting this spec in WebKit.

[annevk]

Is this being maintained? E.g., WICG/keyboard-lock#58 (something I was wondering about as well) from 2020 is still open.

[marcoscaceres]

I discussed the API colleagues and we are concerned with the overall design of the API. Although inherently tied to the Fullscreen API, the integration of the APIs is not handled as gracefully as it could be. The spec itself makes reference to this issue multiple times, suggesting to developers various ways to overcome issues (e.g., call .lock() before .requestFullscreen(), which points to design flaws in the overall design). An alternative approach with better full screen integration could be explored, as is suggested in:
WICG/keyboard-lock#58

Other concerns are normative descriptions of UI behavior, such as:

• “...overlay a message on the screen telling the user that they can Hold the Escape key to exit from fullscreen.”
• “If the key is held for 2 seconds....“

These kinds of normative requirements are overly prescriptive and browser/platform specific behavior. They may not be suitable depending on platform or browser conventions, which is also acknowledged by the specification (e.g., in the Mobile Device Considerations section). This again points to the overall design of API being very “desktop centric” (or, at times, it's OS/Windows centric).

The spec itself also points out a number of potential cross platform incompatibles, which, coupled with the ability for developers to specify their own key-lock combinations seems like it could lead to significant issues. Perhaps such things could be left up to the implementation to handle? In particular, specifying unconventional key locking combinations could lead to user annoyance, and unforeseen (by the developer) internationalization and accessibility issues.

@philn, what are your thoughts on it? Would be great to get your input to come up with a (WebKit) position and perhaps some feedback to send to the WICG.

[marcoscaceres]

Hi @philn, just pinging for an update. If we don't hear back we might mark this as "withdrawn"?

[tomayac]

It would be great to get WebKit's support for this feature, since it can make fullscreen experiences a lot better: https://developer.chrome.com/blog/better-full-screen-mode/.

[annevk]

@tomayac I think that would require someone to step up and deal with the feedback that has been given. I see I filed issues in 2017 that still haven't been resolved.

[jesup]

It looks like no real work has been done (and hardly any comments) to any of the issues filed against this over 3 years ago. It has the appearance of a post-facto spec thrown over the wall after an implementation was done, and then dropped.

[philn]

Hi @philn, just pinging for an update. If we don't hear back we might mark this as "withdrawn"?

Feel free to do that yes.

[xingri]

@philn @marcoscaceres Per the discussion with @annevk on the last WebKit Contributors meeting,
I believe it is still worth to try implementing it based on the current spec draft under the flag.
I filed a bug for implementing this feature. (CC: @jdatapple , @stwrt)

[marcoscaceres]

Sure, but we should fix the spec in parallel too if we can. Otherwise, it may not be possible to unflag this generally given all the issues we've identified (and a lot of code and tests may need to be re-written).

@tomayac, can you check on your side if there is resourcing to collaborate on fixing the API? It's not in a good state and we collaborate on something better.

[xingri]

@marcoscaceres Sure. We also think the enhancement(or clarification) in the specification is needed. We will make sure what it needs to be improved while preparing a draft implementation for the more in-depth discussion of the spec.

[marcoscaceres]

Right, but please don't do that in isolation (we should agree on a design and see if we can get everyone on board). If we need have a call, let's set one up. I'm worried that you will end up implementing a bunch of stuff that we won't be able to land - or you'll end up shipping a design that no one is really happy with, which will confuse developers and the ecosystem.

[xingri]

@marcoscaceres Sounds great! Will get back to you soon.

[marcoscaceres]

Mozilla has an interesting proposal that seems to address a lot of the concerns we raised above. I asked if they are willing to bring it over to the WICG.

Just to be clear, Mozilla proposes just having this as an option when calling .requestFullscreen(), which makes a lot of sense. It also tries to solve for the potential key combination foot guns.

It also makes the API super simple: it reduces the whole thing down to a single dictionary member, which is really elegant.

[xingri]

@marcoscaceres The Mozilla proposal looks good to me but we will review internally and share the feedback.

[jrmuizel]

@marcoscaceres given WebKit/WebKit#21374 has landed does WebKit have an updated standards position?