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

@scheib 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

(Yes let's discuss this below on https://github.com/w3c/pointerlock/pull/49/files#r1373662771) 

> +                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

Use cases served:

1. Changing options.
2. Changing lock targets (including across shadow dom)

I think https://en.wikipedia.org/wiki/Robustness_principle applies here.

Current wording has evolved substantially from the [original](https://www.w3.org/TR/pointerlock/#extensions-to-the-element-interface).

> If any element (including this one), whose shadow-including root is same as this element's shadow-including root, is already locked (or pending lock) the pointer lock target must be updated to this element and a pointerlockchange event sent.


Pre-promise there was not a concern of having multiple asynchronous requests, as they would only resolve eventually with an event.
```js
// Assume an unlocked state, and that these lines execute before the lock is granted.
element1.requestPointerLock(options);
element2.requestPointerLock(options);
// expect change event with element2 as target.
```

Now with promises this is more subtle: 
```js
// Assume an unlocked state, and that these lines execute before the lock is granted.
const promise1 = element1.requestPointerLock(options);
const promise2 = element2.requestPointerLock(options);
```

Mostly, a consistent result needs to be specified. Ideally consistent with current era promise design.

I'd personally (acknowledging that I'm not active in many current specs) suggest:

All promises resolve truthy. There was no reason to block the request. Any code on page expecting success shouldn't be told it failed, because overall lock was obtained.

Before promises the code would have been interpreted as successful. Adding promises shouldn't change that.  We should avoid conflicting error/success state between events and promises.


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

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