Re: [w3c/pointerlock] Add lock options to requestPointerLock (#49)

@marcoscaceres commented on this pull request.



> +                current [=pointer-lock options=] and [=options=] are not
+                supported:
+                  <ol>
+                    <li>[=Queue an element task=] on the [=user interaction
+                    task source=], given this, to perform the following steps:
+                      <ol type='i'>
+                        <li>[=Reject=] <var>promise</var> with a
+                        "{{NotSupportedError}}" {{DOMException}}.
+                        </li>
+                      </ol>
+                    </li>
+                    <li>Return <var>promise</var>.
+                    </li>
+                  </ol>
+                </li>
+                <li>If [=options=] are not equivalent to the current

Thanks for the clarification! that's really helpful and make sense for when the promises have resolved and switching is required (i.e., "happy path uses cases"). 

I'm was just thinking about really simple sync cases (i.e., someone forgets to `await` or consider the following):

```JS
const p1 = element.requestPointerLock({unadjustedMovement: false});
const p2  = element.requestPointerLock({unadjustedMovement: true});
const p3 = element.requestPointerLock({unadjustedMovement: false});

// What happens to p1, p2, and p3? 
```

in the most simple cases, p2 and p3 should be rejected because `p1` hasn't settled yet.  

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/pointerlock/pull/49#discussion_r1426141586
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/pointerlock/pull/49/review/1780899369@github.com>