PSA: Add Permission modals for Keyboard and Pointer Lock

[Muyao Xu]

Contact emails

muy...@google.com

Specification

Keyboard Lock API: https://wicg.github.io/keyboard-lock/

Pointer Lock API: https://www.w3.org/TR/pointerlock-2/

Chrome Status Entry

https://chromestatus.com/feature/5142031990259712

Summary

Show a permission prompt to the user when Keyboard Lock and/or Pointer Lock is requested by a website, and saves the user preferences as content settings. Currently, Keyboard.lock() and Element.requestPointerLock() both return a promise. The returned promise will be resolved if the permission is granted and the promise will be rejected if the permission is denied.

The permission prompt notifies the user that the website is requesting Keyboard Lock and/or Pointer Lock, and allows them to explicitly choose whether to grant or deny those capabilities. This makes it more difficult for malicious websites (e.g., tech support scam websites) to gain the capabilities and prevent the user from exiting the website.

Blink components

Blink>Input

Tracking Bug

crbug.com/314694812

Estimated milestone

M130

[Diego Perez Botero]

Could you please confirm that:
1. Keyboard Lock and Pointer Lock will continue to work in WebView scenarios

2. The new permissions prompt is compatible with full screen (which is a requirement for pointer lock)

If you have an example video or screenshots of the design for the new behavior, that would be super helpful.

[Thomas Steiner]

Created http://cl/672833499 (sorry, this is Google-internal) to document this change. 

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
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/CAJRhUsYNE3X0h6bGqHYPo_eSjRSC50M9sqDTvfWie7-dzpNMJg%40mail.gmail.com.

--

Thomas Steiner, PhD—Developer Relations Engineer (blog.tomayac.com, toot.cafe/@tomayac)

Google Germany GmbH, ABC-Str. 19, 20354 Hamburg, Germany
Geschäftsführer: Paul Manicle, Liana Sebastian
Registergericht und -nummer: Hamburg, HRB 86891

----- BEGIN PGP SIGNATURE -----

Version: GnuPG v2.4.3 (GNU/Linux)

iFy0uwAntT0bE3xtRa5AfeCheCkthAtTh3reSabiGbl0ck

0fjumBl3DCharaCTersAttH3b0ttom.xKcd.cOm/1181.

----- END PGP SIGNATURE -----

[Rick Byers]

Thanks for the heads up on this. Is the functionality complete in 130 already? I.e. is Chrome dev channel suitable for developers to test this behavior and confirm it works OK for their product? Or are there flags that should be turned on for testing still?

I assume this behavior is controlled via finch so that we have a kill-switch if needed (eg. if we get a report of a high-priority issue only once it rolls out to stable)?

Thanks,

   Rick

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

[Muyao Xu]

Hi Rick,

Yes. This is functionality completed in M130 and developers can use the flag chrome://flags/#keyboard-and-pointer-lock-prompt for testing. You can find the list of open bugs here.

Thanks,

Muyao

[Rick Byers]

Perfect, thank you Muyao! Please keep an eye out for reports of issues - the last thing we want to do is break any legitimate uses.

Rick

[Alesandro Ortiz]

Hi Muyao,

The ChromeStatus entry says it's shipping in M131 but the implementation status is still set to "In Development", which I think is preventing it from appearing in the Roadmap page: https://chromestatus.com/roadmap

Because it didn't appear in the Roadmap, I thought it had been postponed again, until I searched for the feature directly in ChromeStatus and still saw the M131 target.

Can you please update the ChromeStatus entry so it appears in the Roadmap and anywhere else that is beneficial for launch comms? https://chromestatus.com/feature/5142031990259712

I think you're following the launch process under the "Web-developer-facing change to existing behavior" scenario which doesn't explicitly say to change the implementation status, unlike the steps for other scenarios, so this might have been a documentation issue.

More broadly, launch comms for this feature has not been as expected [1] [2]. If you can, please chat with DevRel about the launch process for this feature to identify potential improvements based on your experience with this feature. For example, there may be missing steps in the launch docs or elsewhere. Hopefully any improvements prevent similar launch comms issues in the future. Feel free to email me directly about feedback as well.

Thanks for all your work on this feature! Look forward to the launch soon.

Regards,

Alesandro

[Vincent Scheib]

If both keyboard and pointer locks are requested by a page will the user be prompted twice or will the permission be merged into one dialog?

Does the permission dialog explain how to exit the locked state?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4ede18c3-493d-40ab-8560-a2d136f0ebbbn%40chromium.org.

[Muyao Xu]

Hi Vincent, 

> If both keyboard and pointer locks are requested by a page will the user be prompted twice or will the permission be merged into one dialog?

Yes. It will be combined to a single permission model.

> Does the permission dialog explain how to exit the locked state?

No. After the permission is accepted, Chrome shows a toast message at the top of the screen with instructions to exit.

Thanks,

Muyao