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/ac05510e-9e79-487a-9703-1e0624323ed0n%40chromium.org.
