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/29708f9e-2dd8-49cb-8002-6eed4227719en%40chromium.org.
