Thank you,

I have filed requests for the necessary parts and linked to the internal 
launch approvals.

Thanks

On Wednesday, December 10, 2025 at 6:08:20 PM UTC+1 [email protected] 
wrote:

> Note that you'll need to request the other bits in Chromestatus (Privacy, 
> Security, Enterprise, Debuggability and Testing). Off the top of my head I 
> think most are likely N/A with an argument that it's just extending exactly 
> what we have on desktop to one more platform.
>
> For Security you'll probably want an actual review of since implementation 
> details can matter and there may be attempts to abuse pointer lock (eg. 
> trying to trick users into think their system is giving them an error about 
> a virus or something), but perhaps you already have an internal google 
> security review for this feature which will have all the necessary 
> information?
>
> Rick 
>
> On Wed, Dec 10, 2025 at 12:04 PM Rick Byers <[email protected]> wrote:
>
>> LGTM1
>>
>> Expanding this fairly widely used desktop API to Android also (for when 
>> there is a mouse) makes sense to me and seems like it should be 
>> entirely uncontroversial. Thanks for doing it!
>>
>> On Wed, Dec 10, 2025 at 11:39 AM 'Abdelrahman Eed' via blink-dev <
>> [email protected]> wrote:
>>
>>> Re-sending answers, wasn't visible in the thread for some reason (sorry 
>>> if you got it twice):
>>>
>>> Sorry for not providing the desktop details earlier, as I didn't have 
>>> much context since it was originally shipped back in 2014, +
>>> [email protected] in case I provided missing/incorrect information 
>>> about the pointer lock API state on desktop. 
>>>
>>>    -  Was the desktop API reviewed?
>>>    - 
>>>       - The original Pointer lock standard is currently a W3C 
>>>       recommendation: 
>>>       https://www.w3.org/TR/2016/REC-pointerlock-20161027/, since 2016
>>>       - The spec was updated. in 2020: 
>>>       https://www.w3.org/TR/pointerlock-2/ and the update is in a 
>>>       working draft, and already implemented by Chrome Desktop (Chrome 88) 
>>> & 
>>>       Safari (Safari 18.4), there is an open issue on Firefox to implement: 
>>>       https://github.com/mozilla/standards-positions/issues/448
>>>    - Can you file for Gecko/WebKit signals? Did we get signals for the 
>>>    desktop feature?
>>>    - 
>>>       - Gecko: https://github.com/mozilla/standards-positions/issues/448
>>>       - WebKit: shipped 
>>>       https://github.com/WebKit/standards-positions/issues/254
>>>    - Presumably, someone wants to use this?
>>>    - 
>>>       - Yes, there is an open issue 
>>>       <https://issues.chromium.org/issues/40290045> (from 2012) from 
>>>       developers asking support for the Pointer lock API on Android.
>>>    - Is the Desktop feature tested?
>>>    - 
>>>       - wpt: 
>>>       
>>> https://wpt.fyi/results/pointerlock?label=master&label=experimental&aligned&q=pointerlock
>>>    
>>> _____________________________________________
>>>
>>> Will this also be supported in WebView?
>>>
>>>    - Unfortunately no, this release would not support Android WebViews, 
>>>    there are a few issues regarding permissions & window level state 
>>>    modifications that make supporting the pointer lock API on WebViews 
>>>    difficult for now.
>>>
>>> Hope that answered your questions
>>>
>>> Thanks
>>> On Wednesday, December 10, 2025 at 12:45:45 PM UTC+1 Ashley Gullen wrote:
>>>
>>>> Will this also be supported in WebView? Speaking as a web developer, 
>>>> it's very useful to have good compatibility between the browser and 
>>>> webview, especially as there are already a number of APIs that are simply 
>>>> not supported in WebView. The original intent to ship does not appear to 
>>>> comment on WebView support at all.
>>>>
>>>>
>>>>
>>>> On Wed, 10 Dec 2025 at 09:27, Yoav Weiss (@Shopify) <
>>>> [email protected]> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Monday, December 8, 2025 at 3:50:34 PM UTC+1 Chromestatus wrote:
>>>>>
>>>>> *Contact emails*
>>>>> [email protected], [email protected]
>>>>>
>>>>> *Specification*
>>>>> https://www.w3.org/TR/pointerlock-2 
>>>>>
>>>>> *Summary*
>>>>> Provides access to raw mouse movement by locking the target of mouse 
>>>>> events to a single element and hiding the mouse cursor. 
>>>>>
>>>>> *Blink component*
>>>>> Blink>Input>PointerLock 
>>>>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EInput%3EPointerLock%22>
>>>>>
>>>>> *Web Feature ID*
>>>>> pointer-lock <https://webstatus.dev/features/pointer-lock> 
>>>>>
>>>>> *Motivation*
>>>>> The Pointer Lock API provides applications the ability to directly 
>>>>> interpret mouse movements as an input method, rather than being limited 
>>>>> to 
>>>>> only reading the position of the mouse cursor. A popular example is that 
>>>>> of 
>>>>> first person movement controls in three dimensional graphics applications 
>>>>> such as games: movement of the mouse is interpreted to control the 
>>>>> rotation/direction of the player's camera; no mouse cursor is displayed, 
>>>>> and the movement is not limited to the traditional boundaries (such as 
>>>>> the 
>>>>> user agent's window, or the overall screen) that the mouse cursor is 
>>>>> usually subject to, meaning that any mouse movements can be tracked 
>>>>> indefinitely in any direction. See a Simple Demo: (
>>>>> https://mdn.github.io/dom-examples/pointer-lock/), and used in e.g. 
>>>>> Xbox Cloud Gaming, GeForce Now, Amazon Luna, poki.com, crazygames.com, 
>>>>> autodesk.com, etc. The pointer lock API is supported on Desktop 
>>>>> platforms, this feature is for supporting this API for Android. 
>>>>>
>>>>> *Initial public proposal*
>>>>> *No information provided*
>>>>>
>>>>> *TAG review*
>>>>> *No information provided*
>>>>>
>>>>>
>>>>> Was the desktop API reviewed?
>>>>>  
>>>>>
>>>>>
>>>>>
>>>>> *TAG review status*
>>>>> Not applicable 
>>>>>
>>>>> *Risks*
>>>>>
>>>>>
>>>>> *Interoperability and Compatibility*
>>>>> *No information provided* 
>>>>>
>>>>> *Gecko*: No signal
>>>>>
>>>>> *WebKit*: No signal
>>>>>
>>>>>
>>>>> Can you file for Gecko/WebKit signals? Did we get signals for the 
>>>>> desktop feature?
>>>>>  
>>>>>
>>>>>
>>>>> *Web developers*: No signals
>>>>>
>>>>>
>>>>> Presumably, someone wants to use this?
>>>>>  
>>>>>
>>>>>
>>>>> *Other signals*:
>>>>>
>>>>> *WebView application risks*
>>>>>
>>>>> Does this intent deprecate or change behavior of existing APIs, such 
>>>>> that it has potentially high risk for Android WebView-based applications? 
>>>>> *No information provided* 
>>>>>
>>>>>
>>>>> *Debuggability*
>>>>> *No information provided* 
>>>>>
>>>>> *Will this feature be supported on all six Blink platforms (Windows, 
>>>>> Mac, Linux, ChromeOS, Android, and Android WebView)?*
>>>>> No
>>>>>
>>>>> *Is this feature fully tested by web-platform-tests 
>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?*
>>>>> No
>>>>>
>>>>>
>>>>> Is the Desktop feature tested?
>>>>>  
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> *Flag name on about://flags*
>>>>> *No information provided* 
>>>>>
>>>>> *Finch feature name*
>>>>> PointerLockOnAndroid 
>>>>>
>>>>> *Rollout plan*
>>>>> Will ship enabled for all users
>>>>>
>>>>> *Requires code in //chrome?*
>>>>> False
>>>>>
>>>>> *Tracking bug*
>>>>> https://g-issues.chromium.org/issues/40290045
>>>>>
>>>>> *Launch bug*
>>>>> https://launch.corp.google.com/launch/4386186
>>>>>
>>>>> *Estimated milestones*
>>>>> Shipping on Android144 
>>>>>
>>>>> *Anticipated spec changes*
>>>>>
>>>>> Open questions about a feature may be a source of future web compat or 
>>>>> interop issues. Please list open issues (e.g. links to known github 
>>>>> issues 
>>>>> in the project for the feature specification) whose resolution may 
>>>>> introduce web compat/interop risk (e.g., changing to naming or structure 
>>>>> of 
>>>>> the API in a non-backward-compatible way). 
>>>>> *No information provided*
>>>>>
>>>>> *Link to entry on the Chrome Platform Status*
>>>>> https://chromestatus.com/feature/6739764319485952?gate=
>>>>> 4680627611893760
>>>>>
>>>>> This intent message was generated by Chrome Platform Status 
>>>>> <https://chromestatus.com>. 
>>>>>
>>>>> -- 
>>>>> 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 [email protected].
>>>>> To view this discussion visit 
>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c727a2d2-3fb6-405b-8322-db15a32a94f0n%40chromium.org
>>>>>  
>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c727a2d2-3fb6-405b-8322-db15a32a94f0n%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 [email protected].
>>> To view this discussion visit 
>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/ced788f5-87f3-499a-afb3-4fe2f39b2683n%40chromium.org
>>>  
>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/ced788f5-87f3-499a-afb3-4fe2f39b2683n%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 [email protected].
To view this discussion visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a78fb78d-3381-43ab-bf68-5c8c85e27cc2n%40chromium.org.

Reply via email to