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
Add several single and multitouch gestures to simulate various mouse
actions that would otherwise be impossible to perform.
This replaces the old system where you could select which mouse button
a single touch would generate.
This was done a bit arbitrarily before which could easily miss things,
end up in the wrong state and not trigger animations correctly.
This reverts commit c12e5b2b54 and fixes
things in a different way.
Closing the toolbar would make the focus remain on the toolbar and
not in the session. The only way to switch focus was to click in the
session. This commit will automatically switch back focus to the session
after closing the toolbar.
As a rule, instead of hard-coding a behavior on specific platforms we
should do dynamic detection.
This commit moves away from always hiding scrollbars on Android and iOS
and instead detects the rendered width of scrollbars in the browser.
When showing a new status popup we want to set a timer for how long to
show it. In cases where we show many statuses in a fast succession we
need to remove any running timeouts when showing a new one.
There are exceptions when new statuses won't be shown, and thats if a
more severe status is already showing, i.e and error or a warning.
Warnings can still have timeouts. There was a bug that occured when we
tried to show a normal status while a warning was showing. The bug
caused the warning status timeout to be removed even if the normal
status was never shown. We should only remove running timeouts if we're
actually going to show a new status.
If using the extra keys always gives focus to the screen then an
on-screen keyboard would be closed. When using on-screen keyboards we
instead want to give focus to our virtual keyboard input element.
A regression from 2afda54 and friends was that you couldn't use the
extra keys and then directly use the keyboard, you would have to click
in the session first.
This commit restores the correct behavior and also adds a visual queue
to the fact that the screen got the focus by fading the controlbar.
Toggling the enabled state is a remnant from an earlier version
of the code where we could determine if the the session is actually
clipped, and not just that the setting is enabled.
Right now we only change things based on the setting, so let's
completely hide the button when clipping is disabled.
It is not relevant for the connection stage so it should not have
been a constructor argument to begin with. Ship with a warning for
a release before we remove it.
* First attempt to make the fullscreen button work inside an iframe.
* Cleaner distinction between document element and document.
* Scoping corrections. Auto-detect correct iframe.
* Added comments to the relevant sections.
* IE issue fixed.
* Same source issue solved. fullscreenToggle now checks if it is permitted to inspect other iframes.
Previously scrollbars were disabled on all touch devices. This meant
that they were disabled on Windows when touch was detected. Windows does
in fact have useful scrollbars even in touch mode. Fixes Issue #1172
lhchavez