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

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

Combining the discussion in this thread, I propose that we introduce a parallel queue for queuing subsequent lock requests and handle them sequentially. 

Here is the new proposed algorithm.  

```
A requests handling queue (a parallel queue), initially the result of starting a new parallel queue.

When requestPointerLock() invoked, run these steps in parallel:
1. Let promise be a new promise.
2. When this's shadow-including root is the active document of a browsing context (or has an ancestor browsing context) that is not in focus:
    1. Queue an element task on the user interaction task source, given this, to perform the following steps:
        1. Fire an event named pointerlockerror at this's node document.
        2. Reject promise with a "WrongDocumentError" DOMException.     
    2. Return promise.
3. If relevant global object of this does not have transient activation 
    1. Queue an element task on the user interaction task source, given this, to perform the following steps:
        1. Fire an event named pointerlockerror at this's node document.
        2. Reject promise with a "NotAllowedError" DOMException.
    2. Return promise.
4. Enqueue the following steps to requestPointerLock’s requests handling queue:
    1. If this is not connected:
        1. Queue an element task on the user interaction task source, given this, to perform the following steps:
            1. Fire an event named pointerlockerror at this's node document.
            2. Reject promise with a "InvalidStateError" DOMException.
    2. If pointer-lock target is not null and it's shadow-including root is not equal to this's shadow-including root, then:
        1. Queue an element task on the user interaction task source, given this, to perform the following steps:
            1. Fire an event named pointerlockerror at this's node document.
            2. Reject promise with a "InvalidStateError" DOMException.
    3. If options are equivalent to the current pointer-lock options
        1. Set pointer-lock target to this
        2. Queue an element task on the user interaction task source, given this, to perform the following steps:
            1. Fire an event named pointerlockchange at this's node document.
            2. Resolve the promise.
    Note: This enables moving the pointer lock target element.
    4. If pointer-lock target is null, or options is not equivalent to the current pointer-lock options then perform the following steps:
        1. Start the locking request. 
        2. Upon request fulfilled with response.
            1. If response failed:
                1. Queue an element task on the user interaction task source, given this, to perform the following steps:
                    1. Fire an event named pointerlockerror at this's node document.
                    2. Reject promise with a "NotSupportedError" DOMException.
           Note:  An existing lock is not exited if this response failed.
            2. If response succeed:
                1. Update the user agent's pointer-lock target to this element.
                2. Update the user agent's pointer-lock options to options
                4. Queue an element task on the user interaction task source, given this, to perform the following steps:
                    1. Fire an event named pointerlockchange at this's node document.
                    2. Resolve the promise.
5. Return promise.
```

@marcoscaceres / @scheib / @mustaqahmed  please help to review this proposal and share your thoughts.

Thanks!
Alvin

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

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