PointerLock PR#49 meeting note

Date: May 6th, 2024
Attendees: caceres_m@apple.com, jameshoward@mac.com, scheib@google.com,
mustaq@google.com, mattreynolds@google.com, alvinji@google.com

Meeting notes:

   -

   Discussion about concurrent promise request behavior.
   -

      Alvin proposes an algorithm of adding parallel queues and handling
      requests sequentially. Generally no strong objection but will be reviewed
      in the PR before landing it.
      -

   Discussion about the purpose of multiple requests without waiting.
   -

      https://en.wikipedia.org/wiki/Robustness_principle
      -

      Change options or target elements.
      -

      Previous requestLockRequest is non-promise based hence it is valid to
      send requests without waiting, if we reject subsequent requests
will break
      existing sites.
      -

   Propose to add a static field to indicate whether `unadjustedMovement`
   is supported.
   -

      This could be useful to detect whether the option is supported or not
      before directly using it.
      -

      Issue #90 <https://github.com/w3c/pointerlock/issues/90> is created
      to follow this.
      -

   When a subsequent request fails, should we exit the existing lock?
   -

      Issue #91 <https://github.com/w3c/pointerlock/issues/91> is created
      to follow this.
      - Consensus from the meeting
      - Polish PR#49 <https://github.com/w3c/pointerlock/pull/49> and add TODOs
      withassociated open issues then land it soon.


Actions:


   - Alvin to file issue to determine if option should have attribute
   indicating if it works or not ahead of time.
      -

      Issue #90 <https://github.com/w3c/pointerlock/issues/90> is created
      - Alvin to file issue: If lock is active and options are changed with
   new request, should lock be exited?
      -

      Issue #91 <https://github.com/w3c/pointerlock/issues/91> is created
      - Marcos to review comments outstanding and file issues for any that
   need re-review.