Add binding for requestPointerLock option unadjustedMovement: true

[jf908]

Motivation

Providing the { unadjustedMovement: true } option while calling requestPointerLock causes subsequent mouse move events to bypass the OS's mouse acceleration and sensitivity. This is useful for a couple reasons.

1. Many games would rather access raw mouse input, especially for controlling first-person camera movement, so that input acceleration can be disabled or controlled.
2. There is a longstanding Chrome bug where the occasional mouse movement event has an incorrect, very large delta value which causes the cursor to "teleport". Setting unadjustedMovement to true is a workaround for this.

• MDN Example

Proposed Solution

The spec for pointer lock options is unstable so it makes sense to mark this with the unstable flag.

This WebIDL is a start:

dictionary PointerLockOptions {
  boolean unadjustedMovement = false;
};

partial interface Element {
  [NeedsCallerType]
  Promise<undefined> requestPointerLock(optional PointerLockOptions options = {});
};

but there are currently 2 issues I'm encountering with this solution.

1. Since requestPointerLock is already a stable feature, this generates 2 functions with the same name. Is there a way to override an existing function in unstable?
2. requestPointerLock returns undefined on unsupported browsers but Promise<undefined>? returns a parsing error. Any ideas why would this wouldn't work even though there are other functions that return optional values?

Any advice on these issues is welcome!

[daxpedda]

1. Since requestPointerLock is already a stable feature, this generates 2 functions with the same name. Is there a way to override an existing function in unstable?

Remove the optional.

2. requestPointerLock returns undefined on unsupported browsers but Promise<undefined>? returns a parsing error. Any ideas why would this wouldn't work even though there are other functions that return optional values?

Probably just a limitation of the parser/generator. In any case I don't believe that this is something we would want in web-sys anyway, AFAIU the spec will change to return a Promise, so that's what we should align to (in this case a bit weird because it would be a breaking change, but we could still do it for request_pointer_lock_with_options() only).

Detecting and handling browser support is something that web-sys doesn't do, which needs an entirely separate general solution.