If we increase the remote screen size from the server in such a way that
it no longer fits the browser window, the browser will probably want to
show scrollbars. The same happens if you enable 'clipping' while the
remote is larger than the browser window. These scrollbars do, in turn,
decrease the available space in the browser window. This causes our
ResizeObserver to trigger.
If the resize observation triggers a requestRemoteResize() we will
overwrite the size and request a new one just because scrollbars have
appeared. We don't want that.
We can save the expected client size after resizing, and then compare
the current client size with the expected one. If there is no change
compared to the expected size, we shouldn't send the request.
Fixes issue #1616.
This was missed in commit 375f36c575,
probably because these unit tests still passed (due to the expectancy
was for the code to not act on the resize events).
Chrome scrolls the view to show as much as possible of the canvas when
we call focus(), which is likely not the desired behaviour.
This also exposes the ability to pass on future options when focusing
the RFB object manually.
We need to do this in order to safely attach to existing WebSocket
objects. There may be message events already pending so we must set up
our event handlers before returning.
This means we will now throw errors instead of generating "disconnect"
events on problems as the caller no longer has the opportunity to set up
event handlers.
This might have been the correct approach from the start as it mimics
how e.g. the WebSocket constructor works.
We don't know if the caller is prepared to receive those events right
now as normally they would get them on a fresh new stack later. We also
can't delay delivery since then we might deliver the event after any
pending "message" events.
Better to push the problem one layer up to the caller, which now needs
to be more aware of the state of the WebSocket object it is trying to
use.
The previous value made the detection too sensitive and it was very
difficult to scroll precisely. A value of 50 pixels should give similar
behaviour to systems that don't do fine grained scrolling.
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.
If too much text is copied in the session, String.fromCharCode.apply()
would crash in Safari on macOS and Chrome on Linux. This commit fixes
this issue by avoiding apply() altogether. Also added test to cover this
issue.
Supports both classic cursor type and alpha cursor type. In classic
mode the server can send 'inverted' pixels for the cursor, our code
does not support this but handles these pixels as opaque black.
Co-authored-by: Samuel Mannehed <samuel@cendio.se>
Samuel Mannehed
Pierre Ossman
lhchavez
Andrey Trebler
Alex Tanskanen
Niko Lehto