@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 Web Master schrieb am Freitag, 28. Februar 2025 um 22:04:10 UTC+1: > 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 > <https://issues.chromium.org/issues/324520861> 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 > <https://issues.chromium.org/issues/324520861> > > On Friday, 17 January 2025 at 01:17:21 UTC+2 Muyao Xu wrote: > >> 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 >> <https://g-issues.chromium.org/issues/385395442/dependencies> 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 >> >> >> On Mon, Dec 23, 2024 at 6:55 AM Arthur Baker <art...@bloxd.io> wrote: >> >>> 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 >>> >>> On Friday, 20 December 2024 at 13:16:07 UTC Muyao Xu wrote: >>> >>>> 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 >>>> <https://developer.chrome.com/blog/keyboard-lock-pointer-lock-permission> >>>> 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 >>>>> >>>>> On Friday, 27 September 2024 at 20:51:47 UTC+2 Muyao Xu wrote: >>>>> >>>>>> 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. >>>>>> [image: Screenshot 2024-09-27 at 11.47.12 AM.png] >>>>>> >>>>>> > 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.[image: Screenshot >>>>>> 2024-09-27 at 11.51.09 AM.png] >>>>>> >>>>>> Thanks, >>>>>> Muyao >>>>>> >>>>>> On Fri, Sep 27, 2024 at 11:40 AM Vincent Scheib <sch...@chromium.org> >>>>>> wrote: >>>>>> >>>>>>> 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? >>>>>>> >>>>>>> On Thu, Sep 26, 2024 at 1:29 PM Alesandro Ortiz < >>>>>>> ales...@alesandroortiz.com> wrote: >>>>>>> >>>>>>>> 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 >>>>>>>> <https://www.chromium.org/blink/launching-features/#psa-prepare-to-ship>" >>>>>>>> >>>>>>>> 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] >>>>>>>> <https://issues.chromium.org/issues/324147495#comment11> [2] >>>>>>>> <https://issues.chromium.org/issues/314694812#comment4>. 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 >>>>>>>> >>>>>>>> On Wednesday, September 11, 2024 at 4:36:23 PM UTC-4 Rick Byers >>>>>>>> wrote: >>>>>>>> >>>>>>>>> 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 >>>>>>>>> >>>>>>>>> On Wed, Sep 11, 2024 at 4:25 PM Muyao Xu <muy...@google.com> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> 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 >>>>>>>>>> <https://g-issues.chromium.org/issues/314694812/dependencies>. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Muyao >>>>>>>>>> >>>>>>>>>> On Tue, Sep 10, 2024 at 6:45 PM Rick Byers <rby...@chromium.org> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> 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 >>>>>>>>>>> >>>>>>>>>>> On Tue, Sep 10, 2024 at 3:26 AM 'Thomas Steiner' via blink-dev < >>>>>>>>>>> blin...@chromium.org> wrote: >>>>>>>>>>> >>>>>>>>>>>> Created http://cl/672833499 (sorry, this is Google-internal) >>>>>>>>>>>> to document this change. >>>>>>>>>>>> >>>>>>>>>>>> On Tue, Sep 10, 2024 at 1:01 AM 'Muyao Xu' via blink-dev < >>>>>>>>>>>> blin...@chromium.org> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> 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 >>>>>>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EInput> >>>>>>>>>>>>> >>>>>>>>>>>>> Tracking Bug >>>>>>>>>>>>> >>>>>>>>>>>>> crbug.com/314694812 >>>>>>>>>>>>> >>>>>>>>>>>>> Estimated milestone >>>>>>>>>>>>> >>>>>>>>>>>>> M130 >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> 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 >>>>>>>>>>>>> >>>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJRhUsYNE3X0h6bGqHYPo_eSjRSC50M9sqDTvfWie7-dzpNMJg%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>>>>>>>> . >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> 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 ----- >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> 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/CALgRrLmoXtrUG2Sb1QZhNu3Zkp1A3WgFeDQ2fMFS_yUodWeNCQ%40mail.gmail.com >>>>>>>>>>>> >>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALgRrLmoXtrUG2Sb1QZhNu3Zkp1A3WgFeDQ2fMFS_yUodWeNCQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>>>>>>> . >>>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>> 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/4ede18c3-493d-40ab-8560-a2d136f0ebbbn%40chromium.org >>>>>>>> >>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4ede18c3-493d-40ab-8560-a2d136f0ebbbn%40chromium.org?utm_medium=email&utm_source=footer> >>>>>>>> . >>>>>>>> >>>>>>> -- 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+unsubscr...@chromium.org. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b27198a8-568d-4b9c-aa6f-4267bd95598fn%40chromium.org.
