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

@marcoscaceres commented on this pull request.



> +                <li>[=Queue an element task=] on the [=user interaction task
+                source=], given this, to perform the following steps:
+                  <ol>
+                    <li>[=Fire an event=] named {{pointerlockerror}} at
+                    [=this=]'s [=Node/node document=].
+                    </li>
+                    <li>[=Reject=] <var>promise</var> with a
+                    "{{InvalidStateError}}" {{DOMException}}.
+                    </li>
+                  </ol>
+                </li>
+                <li>Return <var>promise</var>.
+                </li>
+              </ol>
+            </li>
+            <li>If the user agent's [=pointer-lock target=]'s

Sorry, I think we might be talking past each other. 

I agree that the following use case is totally valid:
```JS
// Async switching...
await elem.requestPointerLock(options);
await elem.requestPointerLock(differentOptions);
```

I don't agree that this case (sync) is valid or useful: 

```JS
const p1 = elem.requestPointerLock(options);
const p2 = elem.requestPointerLock(differentOptions);
```

I think p2 (and any subsequent call) should reject unless `p1` has settled. 



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

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