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

@mustaqahmed approved this pull request.

I am approving the PR but suggesting to add one more issue.

>            <aside class="note">
-            When a single <a>user activation</a> initiates both pointer lock
-            and fullscreen [[FULLSCREEN]], the {{requestPointerLock()}} call
-            succeeds only when it is made before a fullscreen request because
-            fullscreen is a <a>transient activation-consuming API</a>.
+            This algorithm is under active development and may be modified in

I think we still need to mention how the entries in `lock requests queue` are handled, otherwise the returned `promise` will never be resolved, right?  Looks like we _need_ a Step 8 that posts a task to dequeue all entries.  Without an explicit text, we will leave open the incorrect (?) assumption that all entries will be synchronously dequeued at the end.

I am fine if you quote a new issue saying the `lock requests queue` processing is incomplete.

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

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