It sets KeyboardEvent.key to "Unidentified" for all non-character keys,
which means we must ignore it and use the legacy handling to figure out
the key pressed.
There is some bug in Chrome 119+ on some systems, where it takes
forever for the first readback from a canvas, timing out the first
test that does this.
Work around the issue by increasing the timeout on that platform until
Chrome manages to resolve the issue.
The npm package is supposed to be for CommonJS usage, so only package
that to avoid confusion. This has become an issue now that nodejs
supports ES6 modules, where users are accidentally trying to import the
wrong files and get errors.
The browser might throw an exception right away if there is something it
doesn't like with our connect attempt. E.g. using a non-TLS WebSocket
from a TLS web page.
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.
There is just one argument to inflateInit(). It is inflateInit2() that
takes two arguments.
Since this argument was never used, let's just remove it and keep the
existing behaviour.
This was an accidental copy error from inflator.js. The second argument
to deflateInit() is the compression level, not the window bits.
We have not strong opinions on an appropriate level, so stick to the
default.
Our settings are not a fatal requirement, we can fall back on the
default values if they can't be accessed. A scenario where we've seen
this happen is when cookies are disabled in the browser. It seems
localStorage is disabled along with cookies in these settings.
So, lets log a message about the failure and otherwise silently
continue in this case.
Fixes issue #1577.
We don't know how long the caller will hang on to this data, so we need
to be safe by default and assume it will kept indefinitely. That means
we can't return a reference to the internal buffer, as that will get
overwritten with future messages.
We want to avoid unnecessary copying in performance critical code,
though. So allow code to explicitly ask for a shared buffer, assuming
they know the data needs to be consumed immediately.
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 extra important in the tests where we expect no changes to the
display, as otherwise we can't tell the difference between success and a
decoder that is simply waiting for more data.