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.
There were no test for viewport dragging using gesture previously, so
let's add some.
Note that there currently are some viewport dragging behaviours that we
don't want to have, so some tests have commented out what our desired
behaviour should be.
Previously, these unit tests did not check which events were sent to the
server, only how many events were sent. This commit adds checks to see
that the expected button events are sent.
These functions can be used elsewhere in the tests. We want to use these
in the dragging tests in the future instead of directly calling private
methods.
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.
karma-sinon-chai is not compatible with Chai 5+, and Karma is no longer
being updated.
Load sinon and chai manually instead, until we can have a long term plan
in place.
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.
We should have constants local for the test function when doing
comparisons or we might have false positives because we compare with
buggy values in the code under test.
Avoid poking around in the internals and instead test things using the
official methods and events. This should give us more realistic and
robust tests.
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.
