Servers will assume that a scan code is present if this message type
is used, so fall back to the standard key event message if we don't
know the scan code.
IE and Edge have some corner cases (e.g. Ctrl+key) where we get
insufficient information in the keydown event, and we never get
a keypress event. Try to make a guess of the key in those cases.
iOS sends decent key down events, but junk key up events when a
hardware keyboard is used. This confuses the key tracking as a
corresponding release is then never detected. To work around this
we'll treat the hardware keyboard like the virtual ones and send
the key release right away.
Change back to the old, non-modular recording file format. The new
method doesn't work reliably and there are existing recordings already
out there that we might want to handle.
It doesn't need to be this general as the issue is mostly about
Windows. Also use the same modifier shuffle that RealVNC and
TigerVNC uses to get macOS working well.
The fields provided cannot tell us if it is the left or right
version of the key that's pressed, so they are inherently unreliable.
It is also not a huge problem in practice as we'll get in sync on
the next press or release of the modifier.
Look up keys that are independent of layout and state first,
followed by keys that are only mild variations in layouts.
This is more robust as there might be multiple physical keys
generating the same symbols, and Keysyms don't map directly to
Unicode in all cases.
At the same time switch over to using the modern, standardised
'code' field for lookup.
Use the more modern 'key' field, and remove some legacy fallbacks
that are no longer required. This also removes the "stall" mechanism
as it is not needed with current browsers.
There is a drag-threshold in the panning code which the tests didn't
account for. This caused the tests to fail when window.devicePixelRatio
was higher than 1.
This commit makes vnc_playback.html functional once more, and completely
refactors tests/playback.js to make it usable in other scenarios.
In order for vnc_playback.js to properly load playback files now, they
must `export` their variables.
This updates the tests to work with the new structure, and removes the
old `utils/run_from_console.js` files in favor of just using Karma
directly. The Karma debug page now displays the normal mocha HTML, so
we can use that instead of the HTML generation functionality of the old
test runner.
Note that PhantomJS does not work at the moment (PhantomJS 1.5 should
make it possible to test on PhantomJS again).
Previously, setting `innerHTML` was used to display the statuses. These
could include content communicated from the remote VNC server, allowing
the remove VNC server to inject HTML into the noVNC page.
This commit switches all uses of `innerHTML` to use `textContent`, which
is not vulnerable to the HTML injection.
Do all rendering to a hidden canvas and then copy over the finished
frame to the visible canvas once everything is done. This simplifies
things and solves some bugs as we can retain a copy of the entire
frame buffer.
setTimeout() is subject to delays, possible massive ones. As such it
is rather useless for performance sensitive code. Use the non-standard
setImmediate() API instead, emulating it on postMessage() when it
isn't available.
The hacks needed to run these tests require proper handling of
properties. Unfortunately IE and old versions of Chrome mess up,
so just skip the tests there.
We have to temporarily replace window.navigator due to the fact that
its property languages is read-only. The tests for the translation
utilities require different values of this property. The failing tests
were added in merge of PR #718 (in commit
f5bf2d84ef).
Supports server configurations that might prefer wss:// connections
on the default port, then proxies them through the web server to the
VNC server.
This proxy configuration is helpful on servers using self-signed
certificates. Accessing the https://host/vnc_auto.html page and
adding an exception for that host is sufficient to also satisfy the
wss://host/ request, unlike requests to wss://host:port/ which
may require an extra certificate exception.
RFB's _fail function logs the error, disconnects the session and sets
disconnect_reason. The disconnect_reason is upon disconnection sent to
the user interface. It is thus not suitable for including error details
that aren't user friendly. The idea is that you will look in the
browser console for a full log with details of the error.
Node.js doesn't handle characters high up in the unicode range
properly with charCodeAt(). Adding a new test for UCS-4 codepoints
using codePointAt() to cover this.
There is a specific event for when an image has finished loading,
so trigger on that rather than polling. The polling interval of
requestAnimationFrame() can also be very large.
The callers don't need to concern themselves with how images are
rendered, so hide the details behind the API. This also avoids
exposing the render queue.
The states 'loaded', 'failed' and 'fatal' were all variations of the
'disconnected' state. Removing these states allows us to get rid of
many ugly workarounds and special cases. Error messages to the UI can
now instead be delivered via a new onDisconnected callback.
Names such as 'disconnect' and 'disconnected' are inconsistent in the
way that one describes an action and the other a state. The state that
was called 'normal' didn't fit in with the others because the other
names describe a connection state. The new names are: 'disconnecting',
'connecting' and 'connected'
We already have a callback mechanism for this, so let's use that.
Adds an optional parameter 'msg' to the callback.
Fixes vnc_auto.html (#646) which was broken after
4e0c36dda7
The RFB protocol specifies a max version of 3.8, but RealVNC likes to
increment their version when they add new features. RealVNC 5.3 sends
"005.000" as the version string, since they've extended their
implementation upon RFB v3.8. We can detect that, and just tell them we
only speak 3.8, instead of barfing on "005.000" as an invalid version.
This commit moves all the input-related files from `core/`
to `core/input/`, and renames a couple as relevant
(input.js --> input/devices.js, keyboard.js --> input/util.js).
The event-related wrapper functions in Util existed mainly for
backwards-compat. However, all currently supported browsers
support the standard functions, so these wrappers are no longer needed.
This commits prevents Util from modifying the window object.
- `window.requestAnimFrame` was removed (no polyfill is needed anymore)
- the potential redefinition of `console.log` and friends was removed
(all supported browsers have `console.xyz` defined anyway)
This commit switches over to use PhantomJS 2.x, bringing in a whole host
of improvements (including `Function#bind`, so we can remove the
`Function#bind` shim in core/util.js).
This commit removes our modification of the Array prototype.
It wasn't actually used much in the main code, anyway, and it's a
bad practice to modify built-in prototypes.
This commit restructures noVNC, splitting it into the core directory
and the app directory, with the former containing core noVNC parts,
and the latter containing parts specific to the application.
In input.js, a new keyboard handler was added to deal exclusively
with the QEMU key event extension. '_onKeyPress()' signature
was changed to allow the same method to treat both cases.
The extension will only be enabled if the browser has support
for the KeyboardEvent.code property.
Changes in rfb.js:
- added a new extension code, QEMUExtendedKeyEvent, value -258.
- handleKeyPress now receives 'keyevent' instead of 'keysym' and
'down'. Both values are retrieved from keyevent as they were
in the previous signature. This method now can send QEMU RFB
extended key messages if the flag was set to 'true'.
- tests/test.rfb.js were changed folowing the onKeyPress() signature
change.
- added a new function to send the QEMU extended key message.
Signed-off-by: Daniel Henrique Barboza <danielhb@linux.vnet.ibm.com>
This new file contains the XT scancode mapping that
the extension will use in rfb.js file.
Signed-off-by: Daniel Henrique Barboza <danielhb@linux.vnet.ibm.com>
Instead of requesting frame buffer updates we can, if the server
supports it, continuously recieve frame buffer updates at a rate
determined by the server.
The server can use fencing messages and measure response times to
determine how often it will continue to send updates.
Try to avoid using helper functions with complex logic when verifying
results as those helper functions are also something we want to verify.
Also add a test for a mix of clean and dirty areas specifically to make
sure that helper function behaves properly.
Make sure our messages go away right away, rather than having to
remember to call flush from the caller, or causing extra delays by
waiting for the send timer. This should result in a more responsive
system.
We were completely mishandling the length of the data. Make sure
we look at the length of the websocket rather than the websock object,
and also compare with the expected length.
In order to follow the surrounding coding-standards, the
setDesktopSize client message is split from the public function which
now is called requestDesktopSize().
Pierre Ossman
Samuel Mannehed
Solly Ross
Kyle Russell
Pierre Ossman
Lars Ole Hurlen
Daniel Henrique Barboza