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

[Muyao Xu]

Hi Raf,

We've noticed these issues and plan to roll back the feature. Due to the holidays, we're moving slower than usual and we should start the roll back process by the end of the week.

> 1. Some users click 'never allow', and then we don't have a way to re-trigger the pop-up.

It's not currently supported to re-trigger the permission modal. A workaround is to check the permission state following the guide in this blog and show a message prompting users to enable the permission.

> 2. Users who click 'allow this time' keep getting the popup every second

Does the website request and then release the pointer lock frequently? If users select "allow this time" for the pointer lock permission, they need to grant the permission every time a pointer lock is requested.

I agree that this is not a good user experience if sites need to request pointer lock frequently. Selecting "Always allow" should solve the problem for now. I'll look into alternative implementations such as granting the permission until users navigate away.

Thanks,

Muyao

On Fri, Dec 20, 2024 at 8:45 PM Raf Mertens <r...@crazygames.com> wrote:

Hi everyone,

We've noticed here at CrazyGames that the pointer-lock permission in Chrome 131 is causing some issues for web games.

In particular:
1. Some users click 'never allow', and then we don't have a way to re-trigger the pop-up.
2. Users who click 'allow this time' keep getting the popup every second or so, e.g. in https://www.crazygames.com/game/bullet-force-multiplayer

here's a video: https://drive.google.com/file/d/1_LTfmJGHh4C-tF7e8WzsCAms6wR0ef_V/view?usp=sharing

Without the pointer-lock, many games are unplayable.

We noticed there's this original trial for <Permission /> (https://developer.chrome.com/blog/permission-element-origin-trial), but it doesn't seem to include pointer-lock?

Would anyone here be able to give us some advice? We're happy to discuss in a video call as well.

Best regards,

Raf

[Raf Mertens]

Hi everyone,

We've noticed here at CrazyGames that the pointer-lock permission in Chrome 131 is causing some issues for web games.

In particular:
1. Some users click 'never allow', and then we don't have a way to re-trigger the pop-up.
2. Users who click 'allow this time' keep getting the popup every second or so, e.g. in https://www.crazygames.com/game/bullet-force-multiplayer

here's a video: https://drive.google.com/file/d/1_LTfmJGHh4C-tF7e8WzsCAms6wR0ef_V/view?usp=sharing

Without the pointer-lock, many games are unplayable.

We noticed there's this original trial for <Permission /> (https://developer.chrome.com/blog/permission-element-origin-trial), but it doesn't seem to include pointer-lock?

Would anyone here be able to give us some advice? We're happy to discuss in a video call as well.

Best regards,

Raf

On Friday, 27 September 2024 at 20:51:47 UTC+2 Muyao Xu wrote:

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

[Ashley Gullen]

Hi folks,

FWIW I think this change might have caused this bug where the audio volume is permanently reduced after showing a permission prompt: https://issues.chromium.org/issues/385300194

Ashley

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

[Arthur Baker]

Hi Muyao,

Thanks for rolling this back. I'm not sure what the plan is for re-implementation, but a suggestion for (1): bloxd is (and I'm sure many other sites are) completely unusable without pointer lock. It would be significantly preferable if users kept seeing the pointer lock permission modal upon re-request; than us having to try to teach users how to use chrome's UI. Sites that are functional without pointer lock can simply not re-request it themselves.

Cheers,

Arthur

[Muyao Xu]

Hi all,

I'd like to share some updates on this feature:

1. The pointer lock permission has been removed from the scope because we found that the Pointer Lock API isn't heavily abused like the Keyboard Lock API. We'll add the permission modal for the Keyboard Lock API only.

2. We'll address these issues and run an experiment to see if we've reduced impact on regular use cases (i.e. higher permission grant rate) before proceeding.

Thanks,

Muyao

[Web Master]

Just a passer-by.

As far as I remember, time ago, when Chrome's team initially introduced Fullscreen it was only long press Esc as the escape hatch of Fullscreen mode, but later the X toast was added, if this is true, it means it's solely a design-related decision for Chrome

I personally believe an average end-user outside the world of web development knows what Escape key is and what is meant for, therefore I believe the majority of Chrome users are mature enough to live without the toast...

With that in mind, I was wondering to ask if this long requested feature is about to be implemented any soon ? If not, what about allowing the end-user (in this case, - developer) to write JavaScript that defines native pointer behaviour through the means of Pointer lock API: when cursor is about to hit the top of viewport it locks native cursor, and then quickly release the pointer once the cursor is back to viewport, and most importantly - WITHOUT asking to press Esc to return the native pointer to the screen, as this gives some native non-configurable toast whatsoever. Ultimately, if specification to API is not available, or its prone to security flaws, provide Chrome UI-level customization in user-settings along with default flags.

Thank you.

Feature Request: Hide (X) toast in Fullscreen

[Stefan Benicke]

@Muyao Thanks for your updates on this!

Today I've found a new version of the Keyboard Lock Prompt in Chrome Canary 135.0.7046.0 saying "Override some keys on your keyboard, like Esc".

Even though this is much better than the previous phrase, it is still not clear for normal users what this permission prompt is for. In my opinion there's missing a description like "Override is only active while in fullscreen.".

And furthermore I'm pretty sure that normal users don't know why the app needs to override the keys and that in case of the Escape key override, there's still an option to escape fullscreen with the Escape key.

I also want to note that "some keys on your keyboard" is irritating if Escape is the only key that is locked.

Best regards, Stefan