Intent to ship: Keyboard lock

[Jamie Walch]

Contact emails:
jamie...@chromium.org, zij...@chromium.org, gar...@chromium.org, dah...@chromium.org


Spec:

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

Link to "Intent to Implement":

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


Summary:

Provide a mechanism by which full-screen apps can request keys such as Escape and combinations such as Alt+Tab that would normally be reserved by the browser or the OS. This is important for providing an immersive experience for apps such as games or remote desktop.


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

Windows, Mac, Linux and ChromeOS.

This feature is a no-op on mobile platforms.


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/7320fa047dd71c252b8fd1db7ba743c1f301675a/keyboard-lock


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


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

[Vincent Scheib]

I voice support.

This capability has been raised many times when discussing related features (pointer lock, gamepad, fullscreen) that have are applicable to games, interactive editors, tools, virtual machines, remote desktop environments, etc.  I've noticed these requests often from 2011 to now.

Just as Pointer Lock initially was restricted to Fullscreen, I see value in Keyboard Lock even when similarly limited to fullscreen.  In the long run I also see utility in most reserved keys being accessible even when not fullscreen.

I would like to see this specification further developed, though. E.g. the security section is left with only outstanding issues. I think that is the wrong term for the accessibility and user experience/control considerations, but they should be addressed.

--
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/CABhLwTXB%3D1yy_Bss%2BvGPhUngVi_LULnnOX%3DkZ%3D25hwhhFEFf0Q%40mail.gmail.com.

[Gary Kacmarcik (Кошмарчик)]

On Fri, Sep 1, 2017 at 12:47 PM, Vincent Scheib <sch...@chromium.org> wrote:

I voice support.

This capability has been raised many times when discussing related features (pointer lock, gamepad, fullscreen) that have are applicable to games, interactive editors, tools, virtual machines, remote desktop environments, etc.  I've noticed these requests often from 2011 to now.

Just as Pointer Lock initially was restricted to Fullscreen, I see value in Keyboard Lock even when similarly limited to fullscreen.  In the long run I also see utility in most reserved keys being accessible even when not fullscreen.

I would like to see this specification further developed, though. E.g. the security section is left with only outstanding issues. I think that is the wrong term for the accessibility and user experience/control considerations, but they should be addressed.

I've updated those parts of the spec and we'll continue to update the spec.

[Mounir Lamouri]

Like Vincent, I'm also very supportive but would love to see some more
work on the specification. I've filed some issues [1]. Hopefully, most
of these issues are not blockers.

Regarding Android, do you consider to have an implementation for users
with keyboards in the future? I believe that Alt+Tab would change
activities too and the use case to handle these might be similar. I'm
not sure if there is an API for this though.

[1] https://github.com/w3c/keyboard-lock/issues/created_by/mounirlamouri

Thanks,
-- Mounir

On Sat, 2 Sep 2017, at 01:29, Gary Kacmarcik (Кошмарчик) wrote:
> On Fri, Sep 1, 2017 at 12:47 PM, Vincent Scheib <sch...@chromium.org>
> wrote:
>
> > I voice support.
> >
> > This capability has been raised many times when discussing related
> > features (pointer lock, gamepad, fullscreen) that have are applicable to
> > games, interactive editors, tools, virtual machines, remote desktop
> > environments, etc. I've noticed these requests often from 2011 to now.
> >
> > Just as Pointer Lock initially was restricted to Fullscreen, I see value
> > in Keyboard Lock even when similarly limited to fullscreen. In the long
> > run I also see utility in most reserved keys being accessible even when not
> > fullscreen.
> >
> > I would like to see this specification further developed, though. E.g. the

> > security <https://w3c.github.io/keyboard-lock/#security> section is left

> > with only outstanding issues. I think that is the wrong term for the
> > accessibility and user experience/control considerations, but they should
> > be addressed.
> >
>
> I've updated those parts of the spec and we'll continue to update the
> spec.
>

> --
> --
> Chromium Developers mailing list: chromi...@chromium.org
> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-dev
> ---

> You received this message because you are subscribed to the Google Groups

> "Chromium-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to chromium-dev...@chromium.org.

> To view this discussion on the web visit

> https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAGnkXoEx5D_Ak%3Dj%3D95L_0W2BKNLC4hj40_G2DX1WDmAfRQx60g%40mail.gmail.com.

[Jochen Eisinger]

Hi!

On the intent to implement, I asked for a launch bug to be filed. Can you please point me at it?

thanks

-jochen

--
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/1504443727.803135.1093755416.347698A1%40webmail.messagingengine.com.

[Jamie Walch]

Apologies for missing the request in the intent-to-implement. There's an OWP launch bug in my original email: https://bugs.chromium.org/p/chromium/issues/detail?id=756570; did you mean something different?

> email to chromium-dev+unsubscribe@chromium.org.

> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAGnkXoEx5D_Ak%3Dj%3D95L_0W2BKNLC4hj40_G2DX1WDmAfRQx60g%40mail.gmail.com.

[Jochen Eisinger]

Yes, an OWP launch bug won't trigger e.g. a security review, but only a regular launch bug (Type=Launch)

On Tue, Sep 5, 2017 at 5:39 PM Jamie Walch <jamie...@google.com> wrote:

Apologies for missing the request in the intent-to-implement. There's an OWP launch bug in my original email: https://bugs.chromium.org/p/chromium/issues/detail?id=756570; did you mean something different?

On Tue, Sep 5, 2017 at 5:00 AM, Jochen Eisinger <joc...@chromium.org> wrote:

[Philip Jägenstedt]

Jamie, have you had a change to look at https://github.com/w3c/keyboard-lock/issues/created_by/mounirlamouri? Are there any that you think would lead to normative spec changes + implementation changes?

Are there bugs filed for supporting this feature in Edge, Gecko and WebKit?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALjhuie1r0C%3Db47nPdtGGqMBVJdPQzXcOpe5W%3DwLKk_PoU9xZg%40mail.gmail.com.

[Gary Kacmarcik (Кошмарчик)]

On Sun, Sep 3, 2017 at 6:02 AM, Mounir Lamouri <mou...@lamouri.fr> wrote:

Regarding Android, do you consider to have an implementation for users
with keyboards in the future? I believe that Alt+Tab would change
activities too and the use case to handle these might be similar. I'm
not sure if there is an API for this though.

Explicit support for mobile is something we considered, but we didn't have a compelling use case that we could use to drive the specification.

The fact that keyboards are an optional accessory for mobile, and most mobile devices have a primary touch interface means that we could probably get away with being less restrictive (since Keyboard Lock wouldn't be able to lock you in an app). We might also want to handle keyboard being connected/disconnected.

So, we're open to adding more support for mobile in the future. We didn't add anything now because but we don't have a good sense of the requirements and didn't want to guess.

[Gary Kacmarcik (Кошмарчик)]

On Wed, Sep 6, 2017 at 4:21 AM, Philip Jägenstedt <foo...@google.com> wrote:

Jamie, have you had a change to look at https://github.com/w3c/keyboard-lock/issues/created_by/mounirlamouri? Are there any that you think would lead to normative spec changes + implementation changes?

We've addressed or responded to all the recent comments. None of them required any normative spec changes (although the text and examples were updated for clarity).

   

Are there bugs filed for supporting this feature in Edge, Gecko and WebKit?

Not that I'm aware of.  When this was discussed at TPAC 2016, the general consensus was that, while the feature sounded interesting and useful for advancing the Web Platform, it was not going to be a high priority in the short term.

[owe...@chromium.org]

Excited about this! In terms of launch process, can you please clarify the difference between the following issues:

- https://bugs.chromium.org/p/chromium/issues/detail?id=671774

- https://bugs.chromium.org/p/chromium/issues/detail?id=756570

I also do see a type=launch issue (https://bugs.chromium.org/p/chromium/issues/detail?id=677559) but it doesn't have approvals, so if this is the right issue for this feature it will need approvals.

FYI, in case anyone is confused about the distinction between type=launch and type=launch-owp issues, please note that type=launch-owp issues are now deprecated and were never intended to be used for security / privacy approvals etc.

Finally, since I help out many feature teams shipping new APIs on the web, please don't hesitate to ping me over email or hangouts if you'd like someone to shepherd you through the process and get you approval to launch this, I'd love to see it ship!

[Jamie Walch]

Apologies for the confusion.

https://bugs.chromium.org/p/chromium/issues/detail?id=756570 is the OWP-launch bug I filed because I thought it was a requirement at the time. It sounds like it should be closed at this point, right?

https://bugs.chromium.org/p/chromium/issues/detail?id=671774 appears to be another OWP-launch bug for the same thing filed previously. Presumably it should also be closed.

https://bugs.chromium.org/p/chromium/issues/detail?id=677559 is indeed the correct launch bug. It needs updating with mocks and a design doc, and of course it needs the approvals as you say.

[Jochen Eisinger]

issue 677559 looks good, thank you!

[owe...@chromium.org]

You're welcome to mark either of the owp-launch bugs as obsolete if you already have some other implementation tracking issue to direct people interested in this feature to! There is no formal requirement for either of these.

And sounds good on the launch issue and approvals. Let me know if you need any help :)