In the cursor emulation when deciding if the cursor should be hidden -
Instead of checking what's under the cursor, we check the element that
has capture.
This introduced another bug in the cursor emulation. The cursor did not
always disappear properly when using our cursor emulation together with
our setCapture polyfill. More specifically, we saw a problem when a
capture ended on an element without cursor emulation.
We solved this by introducing another visibility check on a timer in
the cursor emulation. However this led to yet another problem where
this timer conflicted with the timer in the setCapture polyfill.
We removed the timeout in the setCapture polyfill and created a
variable to make sure that all the events remaining in the queue can be
completed.
Co-authored-by: Alex Tanskanen <aleta@cendio.se>
Co-authored-by: Niko Lehto <nikle@cendio.se>
It's not obvious that we want to hide the cursor when we get a leave,
it depends on the element that we're leaving to. This makes the code
more robust.
Co-authored-by: Alex Tanskanen <aleta@cendio.se>
Co-authored-by: Niko Lehto <nikle@cendio.se>
The names of many variables were too similar. To make the code easier
to follow we renamed:
* _captureElem to _capturedElem
* _captureElemChanged() to _capturedElemChanged()
* captureElem to proxyElem
* elem to target
Co-authored-by: Alex Tanskanen <aleta@cendio.se>
Co-authored-by: Niko Lehto <nikle@cendio.se>
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.
Very few browsers are left in the wild that supports modules but not
"nomodule", so let's simplify our handling a bit.
Safari 10 supports modules but not 'nomodule', this means that this
particular version of Safari will be broken. Due to this we have to
bump up the required Safari version to 11.
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>
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.
The cursor object is only attached to our canvas whilst connecting,
so we need to make sure we don't try to update anything when were
not connected or we'll get a crash.
When compacting the receive buffer, we should only copy the bytes
between _rQi and _rQlen (the index of the first unread byte, and the
next write position).
Previously, we copied everything for _rQi up untill the end of the
buffer.
Previously, we would compact the buffer (moving unread data to the
start of the buffer) as follows:
- after processing a message, if there are zero unread bytes, just reset
the indices for first and last unread byte to zero
- else, if at least 1/8th of the buffer is used, copy remaining data to the beginning of the buffer
The second option is never actually necessary, as before inserting new data
into the array, we already check if there's enough free space, and
compact the buffer first if necessary. So we've been doing a lot of
copies that weren't actually needed. Let's not do that any more.
The Firefox workaround which checks for missing Alt key events may
synthesise new KeyboardEvents. On these events, checkAlt should not be
recursively triggered. Otherwise, we get "too much recursion" errors
whenever the Alt key is pressed.
Creating an Ubuntu Snap package to make noVNC easier to deploy.
Checks for the websockify binary in both the PATH (using which) and in the location where the Snap package places the binary. This is necessary for noVNC to be usable in a Snap. It doesn't affect the original functionality of git cloning websockify if it's not found in PATH or the Snap location.
Previously launch.sh would check both for the existence of a local
websockify file and /websockify/run file.
This initial check should really be for a local websockify directory
as in packaged environments a file could very well be the actual
executable leading to launch.sh incorrectly attempting to use a local
version of websockify.
Samuel Mannehed
Pierre Ossman
Niko Lehto
Jesper Alf Dam
Tim Edwards
Shira Maximov
Juanjo Diaz
Lee Yarwood