We want to flush pending mouse moves before we initiate viewport
dragging.
Before this commit, there were scenarios where the _mouseButtonMask
would track a released button as being down.
Instead of keeping track of button states ourselves by looking at
MouseEvent.button, we can use the MouseEvent.buttons which already
contains the state of all buttons.
Since the expected client size wasn't updated when the browser window
resized, noVNC didn't resize the canvas properly when going back to
the exact same dimensions.
Fixes issue #1903
Try to be more consistent in how we capitalize things. Both the "Title
Case" and "Sentence case" styles are popular, so either would work.
Google and Mozilla both prefer "Sentence case", so let's follow them.
Previously, num-lock and caps-lock syncing was performed on a best effort basis by qemu.
Now, the syncing is performed by no-vnc instead. This allows the led state syncing to work
in cases where it previously couldn't, since no-vnc has with this extension knowledge of both
the remote and local capslock and numlock status, which QEMU doesn't have.
The code comment of this code was entirely incorrect, but the commit
message for 5671072 when it was added was correct. I.e. there is a
result, but not a reason.
Adjust the unit tests to make sure this doesn't regress again.
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.
Alexander Zeijlon
Pierre Ossman
Adam Halim
Samuel Mannehed
Andri Yngvason
Mark Peek
Kostiantyn Syrykh
Otto van Houten
Lew Ayotte
pdlan
Frederik Fix
Paul Dumais