We don't have to keep track of this much data between rects, so
restructure things to make it more simple. This allows the JPEG parsing
code to be a pure function which only depends on the input.
This is because, when double-clicking with the trackpad, it will not
highlight the mouse. And this only happened on the iOS but the decision
on adding it a normal user select comes from the other commits that it
looks like it elsewhere.
JavaScript strings use UTF-16 encoding under the hood, but we only want
a single '?' per character we replace. So we need to be more careful
which methods we use when iterating over the clipboard string.
The cut off was wrong here. 3.7 will send a security result, but not a
security reason. It also fixes the issue that < 3.7 (e.g. 3.3) supports
VNC authentication as well.
Avoid the mess of having lots of functions call back to _initMsg() just
because they might be able to continue right away. Instead loop at the
top level until we're either done, or we need more data.
Most (all?) new APIs will require a "secure context", which generally
means served over TLS. We can expect crashes because of missing
functions if this requirement isn't fulfilled, so try to warn the user.
Fixed eslint warnings
Fixing tests that failed
Added unit tests for ARD authentication
Fixed an issue with the ARD rfb version number in the unit tests
Fixed issue with username/password lengths
Username and password lengths are now capped at 63 characters each. Improved code for sign bit on public key bytes.
UTF Encoder username and password before packing it
Change UTF encoding to encode the username and password before packing it to prevent it from being expanded beyond the allowed size. Public key is truncated to proper key length.
Replaced forge with web crypto for ARD authentication
Changed the way in which the async methods are handled, added unit tests to verify ARD encryption output.
Update .eslintignore
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 is no longer an issue on Google Chrome, tested on Chrome 96 on
Fedora 34, Windows 10, macOS 12 and Android 12. It is however an issue
on Safari on macOS 12.
Without this workaround we get scrollbars when making the browser
window smaller, despite remote resize being enabled.
Fixed eslint warnings
Improved memory usage of zrle decoding. Added unit tests for zrle decoding.
Added support for ZRLE encoding
Fixed eslint warnings
Reverted allowIncomplete changes to Inflator
Fixed failing tests for zrle decoder.
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.
This is an error that presents itself with RTCDataChannel's, I suspect this could not
happen with a pre-existing WebSocket.
If the remote connection creates a data channel then the local (VNC) side gets a channel
created callback. It may also be the case that in that very same tick the socket is also
opened and buffered data received. This meant that (in my tests) about 1/3 of the time
noVNC would fail to respond to the initial message from the server because it was received
and subsequently not handled during that initial tick.
Also made the documentation reflect this new behaviour and document the existing behaviour.
Pierre Ossman
Ryo Ota
Lew Ayotte
pdlan
Fredrik Kortetjärvi
Miroslav Šedivý
Frederik Fix
Paul Dumais
Samuel Mannehed
Benjamin Leeds
Tim Stableford
lhchavez