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

@james-howard 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

In my view, p1, p2, and p3 all resolve in order (assuming all other requirements for success are met). I think of the requests as queuing up. The fact that the first two are replaced by the third and aren't active long enough to have any mouse events associated with them isn't an error itself.

If unadjustedMovement isn't supported, then I would expect p1 to resolve, p2 to reject (with NotSupportedError), and then p3 to resolve. My reasoning here is that when options aren't supported, the only action to take is to reject the promise, not to unlock or change the target element.

If there is some other error condition, like we don't have user interaction or the window isn't in focus, then all 3 should reject with that reason.

I think this interpretation is consistent with what's been written so far in this PR.

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

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