The API allowed strings to be passed from the RFB module to the
application using the disconnect reason. This caused problems since
the application didn't have control over translations for these
strings.
Most of the information being passed using this string was very
technical and not helpful to the end user. One exception to this was
the security result information regarding for example authentication
failures. The protocol allows the VNC server to pass a string
directly to the user in the security result.
So the disconnect reason is replaced by a boolean saying if the
disconnection was clean or not. And for the security result information
from the server, a new event has been added.
Instead of exposing all the internal connection states, the RFB module
will now only send events on connect and on disconnect. This makes it
simpler for the application and gets rid of the double events that were
being sent on disconnect (previously updatestate and disconnect).
An RFB object represents a single connection so it doesn't make
sense to have one without it trying to connect right away. Matches
the behaviour of other APIs, e.g. WebSocket.
Use normal properties with JavaScript setters and getters instead of
our homegrown stuff.
This also changes the properties to follow normal naming conventions.
Sort things by category, and organise everything in the same place.
We don't support reuse of RFB objects so we can safely init everything
in the constructor.
Converted version downloaded from sinonjs.org. Fixed version that
doesn't register itself on the global object. This forces all modules to
do a proper import.
The VNC protocol can't handle different deltas or speeds for a mouse
wheel event. When using a device that sends a lot of small mouse wheel
events, instead of fewer larger steps, the effect was that mouse wheel
scrolling was way to sensitive.
This patch looks at the delta of wheel events and doesn't send events
until the combined delta has passed a threshold. Single events that
doesn't pass the threshold get sent after a timeout in order to not
loose any events.
Fixes#577.
Servers will assume that a scan code is present if this message type
is used, so fall back to the standard key event message if we don't
know the scan code.
IE and Edge have some corner cases (e.g. Ctrl+key) where we get
insufficient information in the keydown event, and we never get
a keypress event. Try to make a guess of the key in those cases.
iOS sends decent key down events, but junk key up events when a
hardware keyboard is used. This confuses the key tracking as a
corresponding release is then never detected. To work around this
we'll treat the hardware keyboard like the virtual ones and send
the key release right away.
Samuel Mannehed
Pierre Ossman