Intent to ship: Keyboard lock

[Joe Downing]

Contact emails:

joe...@chromium.org, jamie...@chromium.org, gar...@chromium.org, den...@chromium.org

Explainer:

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

Spec:

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

TAG review:

https://github.com/w3ctag/design-reviews/issues/192

Design Doc:

https://docs.google.com/document/d/1z8_VDDj5qrixHxXYeYrotJna_lsBtpzfL7uFKj7F3sA

Link to "Intent to Implement":

https://groups.google.com/a/chromium.org/d/topic/blink-dev/9pauQUAvrcw/discussion

Link to previous, slightly premature, "Intent to Ship" request:

https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/XdIsb1IFGrI/discussion

Summary:

Provide a mechanism by which full-screen websites can request keys, such as Escape, keyboard combinations that would normally be reserved by the browser, such as Ctrl+T, and system shortcuts, such as Alt+Tab.

While browser-level shortcut handling is implemented uniformly across all target platforms, there are per-platform variations in the system shortcuts handled.  These variations are due to platform constraints which are beyond the control of an app running in user mode.

This functionality is important for providing an immersive experience for games and remote desktop websites.

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Browser-level keyboard lock, which handles escape and browser shortcuts, will be enabled for all desktop platforms: Windows, Mac, Linux, and ChromeOS.

System-level keyboard lock, which handles system shortcuts, will be enabled for Windows, Linux, and ChromeOS.  

MacOS requires additional work to address technical constraints unique to that platform, this work is planned for the next milestone (M69).

We have no plans for supporting Android.

Compatibility Risk:

Medium; this is a new feature and Chrome is the first to ship it.

Microsoft, Mozilla, Yandex: Interested and supportive of the idea, but no immediate plans to implement.

Apple: No public signals.

Link to web-platform-tests:
https://github.com/w3c/web-platform-tests/tree/master/keyboard-lock

OWP launch tracking bug:
https://bugs.chromium.org/p/chromium/issues/detail?id=677559

Entry on the feature dashboard:
https://www.chromestatus.com/feature/5642959835889664

[Alex Russell]

Very happy to see this move forward, and grateful to see both a great Explainer doc and a Secure Contexts restriction.

LGTM1!

[Rick Byers]

LGTM2

On Thu, May 10, 2018 at 12:35 PM, 'Alex Russell' via blink-dev <blin...@chromium.org> wrote:

Very happy to see this move forward, and grateful to see both a great Explainer doc and a Secure Contexts restriction.

LGTM1!

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/036f82a6-8083-410d-ac57-7f5a932d6318%40chromium.org.

[Philip Jägenstedt]

Pretty soon we'll be able to use wpt.fyi to judge the test results before shipping. Preview:

https://master-dot-wptdashboard.appspot.com/results/keyboard-lock?label=experimental

Are the failures here because the feature isn't enabled even behind the experimental flag?

(Bugs in the runner setup are also possible.)

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY_x%2Bb4syZJSwrVytu%2B6Y%3Dp%3D5c-0%3D0OB7T0-DJsdsEwaQg%40mail.gmail.com.

[Chris Harrelson]

LGTM3

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYdf4_dyfBvqVcmTZs-SOrEDRWzP648XgCSoBqgTmynshA%40mail.gmail.com.

[joe...@google.com]

I looked at the test and I think they are failing because the feature isn't being enabled.  Here is an example failure:

Failure message: Cannot read property 'lock' of undefined

The calling pattern for this API is navigator.keyboard.lock() so it seems like the keyboard node is not being enabled via the flag.  My suspicion is that this is because the blink feature flag was set to 'test' and not 'experimental' so enabling experimental APIs would not have enabled KeyboardLock.  This should be resolved now that the flag has been updated to 'stable'.  I'll keep an eye out for this and make sure it passes once my change is committed.

Thanks,

Joe

[Philip Jägenstedt]

Ah, that explains it, thanks! In a week or however long it takes things to reach Chrome Dev there should be updated results to look at. (Unfortunately there's no Chrome Canary for Linux.)

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d8e67360-0a34-44cf-bd16-d4ad592d3c0b%40chromium.org.

[joe...@google.com]

FYI, all of the tests are passing now for M68:

https://master-dot-wptdashboard.appspot.com/results/keyboard-lock?label=experimental

Joe

[Philip Jägenstedt]

That is excellent, thank you Joe!

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4c80bebe-79d4-4c45-aa3d-0c467fec779a%40chromium.org.