Intent To Ship: Pointer Lock Unadjusted Movement

[James Hollyer]

---

Title:

Intent to Ship: Unadjusted Movement

Body:

Contact emails

jamesh...@google.com, reillyg@google.com 

Explainer

No explainer because this is simple enough to explain right here.

Spec

Spec pull request

No tag review. This spec change seems small enough to not warrant a tag review.

Summary

The goal of this change is to allow application to access unadjusted mouse movement data while in Pointer Lock. This is a highly requested feature from partners in the gaming space. This change adds a PointerLockOptions object as a parameter to the requestPointerLock() method. The PointerLockOptions object currently only has one useful member which is the boolean unadjustedMovement. Also, to properly return error information and make it easier for developers to implement the requestPointerLock method was changed to return a promise.

The existing Pointer Lock API returns the mouse movement that the platforms give Chrome.  By default all platforms include some form of mouse acceleration in the movement information they give Chrome. Mouse acceleration is the artificial increase of velocity when the mouse is moving fast. This is useful in normal use of the pointer when a user is trying to move the mouse across the screen. However, it also makes aiming in first person perspective games very difficult. To solve this problem we are adding an option to get that unadjusted movement data when requesting pointer lock.  

With Pointer Lock options now available, applications need the ability to change those options while keeping the lock. This proves difficult using the previous API which fired changed or error events on the document to indicate the result of the request. Particularly troublesome was that the error event gave no reason. To solve this problem for developers a Promise workflow is being introduced. Now when requesting a change the developers can get actionable error information on rejected requests.

Example:

try {

  await element.requestPointerLock({ unadjustedMovement: true });

  console.log(“pointer lock acquired”);

} catch (error) {

  console.log(`Failed to acquire pointer lock due to ${error}`);

}

Link to Intents

Intent to Experiment

Intent to Prototype

Link to Origin Trial feedback summary

Developer feedback was solicited on the bug. There is one comment that was addressed in a separate issue and a discussion with the developer who made the comment. Our partners deployed changes to use this API and provided feedback on the design.

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

This is available on all desktop platforms. Since this new option is about the mouse it does not make sense to have this on mobile.

Demo link

This site displays the difference in mouse movement.

Debuggability

Debugging this change is done through error messages in the rejection of the promise.

Risks

Interoperability and Compatibility

The spec pull request is here. There was some response from Firefox in the beginning but that stopped a while ago. Here are the official request for positions:

• Request to Gecko

• Request to Webkit

Ergonomics

This feature is frequently used with the Fullscreen API and there have been some problems with the two being used simultaneously which have been resolved. All members of the Origin Trial use these two in correlation successfully.

Activation

This will not break current users of the Pointer Lock API. However, developers do need to add the option in the request and use the Promise structure to take advantage of the new features.

Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.

Here is the pull request for tentative Web Platform Tests which will be marked stable once the PR above is merged.

Actual testing of adjusted vs. unadjusted movement is very difficult to automate as it is dependent on platform-specific behavior and requires a hardware test setup to simulate mouse movements at a very low level.

Entry on the feature dashboard

https://www.chromestatus.com/features/5723553087356928

[Alex Russell]

Hey James,

Regarding TAG review and Explainers, it's important that we not skip steps. I'd like to see this ship, but we also need to be following our own process, particularly given that we don't have other implementers signed up to ship this.

Happy to follow up offline.

Regards

[James Hollyer]

Explainer has been created and Tag informed.

---

Title:

Intent to Ship: Unadjusted Movement

Body:

Contact emails

jamesh...@google.com, reillyg@google.com 

Explainer

https://github.com/slightlyoff/unadjusted_pointer_lock_explainer

Spec

Spec pull request

No tag review. However TAG has been informed and agreed this did not need a full review.

[Yoav Weiss]

LGTM1

On Wed, Nov 25, 2020 at 10:30 PM 'James Hollyer' via blink-dev <blin...@chromium.org> wrote:

Explainer has been created and Tag informed.

The explainer is very helpful. Thank you!

 

--
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/CAPV%3DugzCLtGPqFOu4UbasNkVqaGD0tKSaOBQ-jehYRGCDGGSFA%40mail.gmail.com.

[Daniel Bratell]

LGTM2

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEg076ez3g%3Daakbd36GdFD5wmfgELUEbijbFMyw%2BCNFExw%40mail.gmail.com.

[Manuel Rego Casasnovas]

It's not nice that other vendors haven't replied to the signals requests
(despite they have been filled a while ago), as this is an API that has
support in other browsers right now too.

If I understood correctly this has two changes:
* Add unadjustedMovement option to requestPointerLock().
* Make requestPointerLock() to return a promise.

And I have 2 questions:
* I think there's some interop risk if people start to use the new
promise API in browsers that doesn't implement that yet.
For example if sites start to use the promise API like:
el.requestPointerLock().then(...);
They'll get errors in other browsers not returning a promise yet.
Should the documentation explain a clear way to avoid this with some way
to feature detect it?

* On the explainer there is a mention to some fingerprinting concerns,
I'm curious if this has been checked with other vendors?

Bye,
Rego

On 26/11/2020 10:19, Daniel Bratell wrote:
> LGTM2
>
> /Daniel
>
>
> On 2020-11-26 07:09, Yoav Weiss wrote:
>> LGTM1
>>
>> On Wed, Nov 25, 2020 at 10:30 PM 'James Hollyer' via blink-dev
>> <blin...@chromium.org <mailto:blin...@chromium.org>> wrote:
>>
>> Explainer has been created and Tag informed.
>>
>>
>> The explainer is very helpful. Thank you!
>>
>>

>> ------------------------------------------------------------------------

>>
>> Title:
>>
>>
>> Intent to Ship: Unadjusted Movement
>>
>>
>> Body:
>>
>>
>> Contact emails
>>

>> jamesh...@google.com <mailto:jamesh...@google.com>,
>> rei...@google.com <http://google.com>
>>
>>
>> Explainer
>>
>> https://github.com/slightlyoff/unadjusted_pointer_lock_explainer
>> <https://github.com/slightlyoff/unadjusted_pointer_lock_explainer>
>>
>>
>> Spec
>>
>> Spec pull request <https://github.com/w3c/pointerlock/pull/49>

>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/EL_IQ4BKpT0/m/6iBHvyTmDQAJ>
>>
>> Intent to Prototype
>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/qZ_STHiTDzU/m/agsdSkVpDgAJ>

>>
>>
>> Link to Origin Trial feedback summary
>>
>> Developer feedback was solicited on the bug

>> <https://bugs.chromium.org/p/chromium/issues/detail?id=1042062&q=owner%3Ame%20pointer%20lock&can=2>.

>> There is one comment that was addressed in a separate issue and a
>> discussion with the developer who made the comment. Our partners
>> deployed changes to use this API and provided feedback on the design.
>>
>>
>> Is this feature supported on all six Blink platforms (Windows,
>> Mac, Linux, Chrome OS, Android, and Android WebView)?
>>
>> This is available on all desktop platforms. Since this new option
>> is about the mouse it does not make sense to have this on mobile.
>>
>>
>> Demo link
>>
>> This site

>> <https://jameshollyer.github.io/unadjusted-movement-test/>displays

>> the difference in mouse movement.
>>
>>
>> Debuggability
>>
>> Debugging this change is done through error messages in the
>> rejection of the promise.
>>
>>
>> Risks
>>
>> Interoperability and Compatibility
>>
>> The spec pull request is here

>> <https://github.com/w3c/pointerlock/pull/49>. There was some

>> response from Firefox in the beginning but that stopped a while
>> ago. Here are the official request for positions:
>>
>>

>> *
>>
>> Request to Gecko
>> <https://github.com/mozilla/standards-positions/issues/448>
>>
>> *
>>
>> Request to Webkit
>> <https://lists.webkit.org/pipermail/webkit-dev/2020-October/031473.html>

>>
>>
>> Ergonomics
>>
>> This feature is frequently used with the Fullscreen API and there
>> have been some problems with the two being used simultaneously
>> which have been resolved. All members of the Origin Trial use
>> these two in correlation successfully.
>>
>>
>> Activation
>>
>> This will not break current users of the Pointer Lock API.
>> However, developers do need to add the option in the request and
>> use the Promise structure to take advantage of the new features.
>>
>>
>> Is this feature fully tested by web-platform-tests

>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>?
>> Link to test suite results from wpt.fyi <https://wpt.fyi>.

>>
>>
>> Here is the pull request for tentative Web Platform Tests

>> <https://github.com/web-platform-tests/wpt/pull/26195>which will

>> be marked stable once the PR above is merged.
>>
>>
>> Actual testing of adjusted vs. unadjusted movement is very
>> difficult to automate as it is dependent on platform-specific
>> behavior and requires a hardware test setup to simulate mouse
>> movements at a very low level.
>>
>>
>> Entry on the feature dashboard
>>
>> https://www.chromestatus.com/features/5723553087356928
>> <https://www.chromestatus.com/features/5723553087356928>
>>
>>
>>
>> On Thu, Oct 22, 2020 at 12:32 PM Alex Russell
>> <sligh...@chromium.org <mailto:sligh...@chromium.org>> wrote:
>>
>> Hey James,
>>
>> Regarding TAG review and Explainers, it's important that we
>> not skip steps. I'd like to see this ship, but we also need to
>> be following our own process, particularly given that we don't
>> have other implementers signed up to ship this.
>>
>> Happy to follow up offline.
>>
>> Regards
>>
>> On Wednesday, October 21, 2020 at 4:54:11 PM UTC-7 James
>> Hollyer wrote:
>>

>> ------------------------------------------------------------------------

>>
>> Title:
>>
>>
>> Intent to Ship: Unadjusted Movement
>>
>>
>> Body:
>>
>>
>> Contact emails
>>

>> jamesh...@google.com, rei...@google.com <http://google.com>

>>
>>
>> Explainer
>>
>> No explainer because this is simple enough to explain
>> right here.
>>
>>
>> Spec
>>

>> Spec pull request <https://github.com/w3c/pointerlock/pull/49>

>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/EL_IQ4BKpT0/m/6iBHvyTmDQAJ>
>>
>> Intent to Prototype
>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/qZ_STHiTDzU/m/agsdSkVpDgAJ>

>>
>>
>> Link to Origin Trial feedback summary
>>
>> Developer feedback was solicited on the bug

>> <https://bugs.chromium.org/p/chromium/issues/detail?id=1042062&q=owner%3Ame%20pointer%20lock&can=2>.

>> There is one comment that was addressed in a separate
>> issue and a discussion with the developer who made the
>> comment. Our partners deployed changes to use this API and
>> provided feedback on the design.
>>
>>
>> Is this feature supported on all six Blink platforms
>> (Windows, Mac, Linux, Chrome OS, Android, and Android
>> WebView)?
>>
>> This is available on all desktop platforms. Since this new
>> option is about the mouse it does not make sense to have
>> this on mobile.
>>
>>
>> Demo link
>>
>> This site

>> <https://jameshollyer.github.io/unadjusted-movement-test/>displays

>> the difference in mouse movement.
>>
>>
>> Debuggability
>>
>> Debugging this change is done through error messages in
>> the rejection of the promise.
>>
>>
>> Risks
>>
>> Interoperability and Compatibility
>>
>> The spec pull request is here

>> <https://github.com/w3c/pointerlock/pull/49>. There was

>> some response from Firefox in the beginning but that
>> stopped a while ago. Here are the official request for
>> positions:
>>
>>

>> *
>>
>> Request to Gecko
>> <https://github.com/mozilla/standards-positions/issues/448>
>>
>> *
>>
>> Request to Webkit
>> <https://lists.webkit.org/pipermail/webkit-dev/2020-October/031473.html>

>>
>>
>> Ergonomics
>>
>> This feature is frequently used with the Fullscreen API
>> and there have been some problems with the two being used
>> simultaneously which have been resolved. All members of
>> the Origin Trial use these two in correlation successfully.
>>
>>
>> Activation
>>
>> This will not break current users of the Pointer Lock API.
>> However, developers do need to add the option in the
>> request and use the Promise structure to take advantage of
>> the new features.
>>
>>
>> Is this feature fully tested by web-platform-tests

>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>?
>> Link to test suite results from wpt.fyi <https://wpt.fyi>.

>>
>>
>> Here is the pull request for tentative Web Platform Tests

>> <https://github.com/web-platform-tests/wpt/pull/26195>which will

>> be marked stable once the PR above is merged.
>>
>>
>> Actual testing of adjusted vs. unadjusted movement is very
>> difficult to automate as it is dependent on
>> platform-specific behavior and requires a hardware test
>> setup to simulate mouse movements at a very low level.
>>
>>
>> Entry on the feature dashboard
>>
>> https://www.chromestatus.com/features/5723553087356928

>> <https://www.chromestatus.com/features/5723553087356928>
>>
>>
>> --
>> 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

>> <mailto:blink-dev+...@chromium.org>.

>> To view this discussion on the web visit
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPV%3DugzCLtGPqFOu4UbasNkVqaGD0tKSaOBQ-jehYRGCDGGSFA%40mail.gmail.com

>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPV%3DugzCLtGPqFOu4UbasNkVqaGD0tKSaOBQ-jehYRGCDGGSFA%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

>> <mailto:blink-dev+...@chromium.org>.

>> To view this discussion on the web visit

>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEg076ez3g%3Daakbd36GdFD5wmfgELUEbijbFMyw%2BCNFExw%40mail.gmail.com
>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEg076ez3g%3Daakbd36GdFD5wmfgELUEbijbFMyw%2BCNFExw%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

> <mailto:blink-dev+...@chromium.org>.

> To view this discussion on the web visit

> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8eeac7eb-429f-a91d-2c1f-75752f834a91%40gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8eeac7eb-429f-a91d-2c1f-75752f834a91%40gmail.com?utm_medium=email&utm_source=footer>.

[François Beaufort 🇫🇷]

On Fri, Nov 27, 2020 at 3:43 PM Manuel Rego Casasnovas <re...@igalia.com> wrote:

It's not nice that other vendors haven't replied to the signals requests
(despite they have been filled a while ago), as this is an API that has
support in other browsers right now too.

If I understood correctly this has two changes:
* Add unadjustedMovement option to requestPointerLock().
* Make requestPointerLock() to return a promise.

And I have 2 questions:
* I think there's some interop risk if people start to use the new
promise API in browsers that doesn't implement that yet.
   For example if sites start to use the promise API like:
     el.requestPointerLock().then(...);
   They'll get errors in other browsers not returning a promise yet.
Should the documentation explain a clear way to avoid this with some way
to feature detect it?

Hopefully, documentation at https://web.dev/disable-mouse-acceleration/#disable-mouse-acceleration shows how to handle this.
 

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/54ba5532-73e4-0d8a-3414-e40186f40d94%40igalia.com.

[Thomas Nattestad]

Hello blink-dev and API owners,

When we sent the intent to ship, we missed including a request for an exception to the 1 week of breakage common at the end of an origin trial before stable release. Given the active adoption and feedback we've heard from partners, we think avoiding this risk seems reasonable. If there is any additional validation you'd like to show to avoid the one week of breakage, please let us know :) Apologies for not including this in the original intent to ship 

Sincerely,
Thomas 

[Manuel Rego Casasnovas]

On 27/11/2020 15:48, 'François Beaufort 🇫🇷' via blink-dev wrote:
> And I have 2 questions:
> * I think there's some interop risk if people start to use the new
> promise API in browsers that doesn't implement that yet.
>    For example if sites start to use the promise API like:
>      el.requestPointerLock().then(...);
>    They'll get errors in other browsers not returning a promise yet.
> Should the documentation explain a clear way to avoid this with some
> way
> to feature detect it?
>
>
> Hopefully, documentation at
> https://web.dev/disable-mouse-acceleration/#disable-mouse-acceleration
> <https://web.dev/disable-mouse-acceleration/#disable-mouse-acceleration>
> shows how to handle this.

Thanks, that's useful. Also updating MDN would be nice.

> * On the explainer there is a mention to some fingerprinting concerns,
> I'm curious if this has been checked with other vendors?

This question hasn't been answer yet, I'm still curious if this was
agreed with other vendors in some standards discussion or anything. If
we've got not feedback yet, I guess we should just try to be on top of
this when other browsers are willing to implement this.

Anyway LGTM3 from my side.

Bye,
Rego

[James Hollyer]

The simple answer is no. I was unable to get any responses from other vendors about fingerprinting concerns. The only response we have gotten was in this issue which was a while ago and was just discussing the viability of the feature and there was nothing about fingerprinting. 

At this year's virtual TPAC I discussed this change in a Web Apps working group meeting in order to try to get some discussion from other vendors but nothing came of it. In my brief presentation to the group I did not mention fingerprinting concerns.

Marcos Cáceres has taken a look at this as a third party but, he is not currently with any other browser vendor.

--
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/59751da7-032a-a28a-7a94-b03ceb37533f%40igalia.com.

[Mike West]

I don't think we responded to this specific bit: my understanding is that you have clear use cases with developers that have provided feedback, and have convinced both themselves and you that the API as it's implemented solves their problem in a robust way. So, LGTM for this specifically.

-mike

[Joe Medley]

"Thanks, that's useful. Also updating MDN would be nice."

I can help you with that. This will be on my list for sure, Reach out to me as soon as your feature is merged to a numbered branch.

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195

If an API's not documented it doesn't exist.

--
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/59751da7-032a-a28a-7a94-b03ceb37533f%40igalia.com.

[James Hollyer]

Can we get a response to Thomas's request for an exception to the 1 week of breakage?

Our partners are really pushing to get this exception but they need to know either way so they can start informing their users of the interruption. 

Apologies again for not including this in the original I2S this was my first one.

Thanks

-James

[Chris Harrelson]

On Wed, Dec 16, 2020 at 3:25 PM 'James Hollyer' via blink-dev <blin...@chromium.org> wrote:

Can we get a response to Thomas's request for an exception to the 1 week of breakage?

Mike did respond to that and that is what his LGTM is for. It does look like we are missing a third overall LGTM though, I will follow up.

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/cfb49341-0be5-4efc-957e-ac7a1b9a3fc9n%40chromium.org.

[Chris Harrelson]

Actually, scratch that. We do have 3 LGTMs. So you're good to go!