This new API can now be used to support [keyboard
lock](https://web.dev/keyboard-lock/), although support for that is
limited to Chrome only at the moment.
This change adds the following:
a) A new button on the UI to enter full pointer lock mode, which invokes
the Pointer Lock API[1] on the canvas, which hides the cursor and
makes mouse events provide relative motion from the previous event
(through `movementX` and `movementY`). These can be added to the
previously-known mouse position to convert it back to an absolute
position.
b) Adds support for the VMware Cursor Position pseudo-encoding[2], which
servers can use when they make cursor position changes themselves.
This is done by some APIs like SDL, when they detect that the client
does not support relative mouse movement[3] and then "warp"[4] the
cursor to the center of the window, to calculate the relative mouse
motion themselves.
c) When the canvas is in pointer lock mode and the cursor is not being
locally displayed, it updates the cursor position with the
information that the server sends, since the actual position of the
cursor does not matter locally anymore, since it's not visible.
d) Adds some tests for the above.
You can try this out end-to-end with TigerVNC with
https://github.com/TigerVNC/tigervnc/pull/1198 applied!
Fixes: #1493 under some circumstances (at least all SDL games would now
work).
1: https://developer.mozilla.org/en-US/docs/Web/API/Pointer_Lock_API
2: https://github.com/rfbproto/rfbproto/blob/master/rfbproto.rst#vmware-cursor-position-pseudo-encoding
3: https://hg.libsdl.org/SDL/file/28e3b60e2131/src/events/SDL_mouse.c#l804
4: https://tronche.com/gui/x/xlib/input/XWarpPointer.html
Windows behaves very oddly for some Japanese IM keys in that it won't
send a key release event when the key is released. In some keys it never
sends the event, and in some cases it sends the release as the key is
pressed the subsequent time.
Windows doesn't give us stable symbols for a bunch of Japanese IM keys,
instead alternating between two symbols. This state is not synchronised
with the IM running on the remote server so to have stable behaviour we
have to collapse these multiple symbols in to a single keysym.
These are very pointless for the server to send, but not a violation of
the protocol so we need to be able to handle them. We've seen this
happen in real world scenarios a few times.
lhchavez