To run unit tests:
$ cd noVNC/tests
$ npm install mocha
$ npm install chai
<open keyboard-tests.html in a browser>
To manually test:
<open keytest.html in a browser>
Design overview:
The big complex browser-dependent keyboard input events are replaced by custom
objects containing only the data we put there. These objects always have a
'keyId' property, which is mainly used to compare events, to determine if
they represent the same key (in order to match keydown/keypress/keyup
events for the same key together), and do not have a 'keysym' property
until we know that the specified keysym should be sent to the VNC server.
(In other words, even if we know which keysym a keypress represents, a
'keysym' property is not added to the object until we also know that the
keysym should be sent as-is to the VNC server.
Modifiers are divided into two groups: char modifiers and shortcut
modifiers. The latter never have an effect in themselves, but an
application may react to them to implement keyboard shortcuts (CTRL-C for
example). The former *may* be used to transform the character they are
combined with, and in those cases, the modifier press itself should not be
sent to the VNC server. For example, AltGr on European keyboards can be
combined with many, but not all, keys, to produce different characters.
The new keyboard handling is effectively a pipeline where each stage
performs a single well-defined transformation to clean up the input and
eliminate browser quirks. It can easily be extended with new stages, but
currently consists of the following:
1. KeyEventDecoder: takes the raw keydown/keyup/keypress event sent by the
browser, and converts it to our custom event wrapper, adding some hints
for later stages. If we get a keydown event, and we can't rely on getting
a subsequent keypress with more accurate information, we also try to
determine the keysym here. Also uses a ModifierSync object to keep track
of the state of modifier keys, and insert fake events to compensate when
the browser forgets to generate modifier key events.
2. VerifyCharModifier: When a char modifier is combined with another key,
we need to know if this creates a new keypress (for example AltGr + 2 on a
DK keyboard yields @), or if it has no effect. This stage handles this by
"stalling" the pipeline in cases where this is uncertain, giving us time
to see if a keypress event is coming.
3. TrackKeyState: since some browsers forget to send keyup events, we need
to keep track of which keys are currently down. This also means we need to
"collapse" keydown and keypress events into one: only one of them should
result in an event sent to the VNC server.
4. EscapeModifiers: when a char modifier is used to generate a character
(say, AltGr creating a @), we need to "undo" the modifier itself while
sending the character - the VNC server should see the sequence
keyup(AltGr), keydown(@), keydown(AltGr), keyup(@).
the commenting!
Correctly identifies the use of http/https and forces the value of port to 80 and 443
respectively, as in this situation window.location.port is blank.
This is patch includes the same changes as made in vnc_auto.html
FBU.bytes must be set before return false to indicate that the FBU
header has been read. If not set then "if (FBU.bytes == 0) { ..}"
in framebufferUpdate will be entered and the copyrect header will
be interpreted as a new FBU leading to a "unsupported encoding"
disconnect error.
Browsers (such as Chrome) don't report port numbers in window.location.port when
used on standard ports such as 80 and 443. This causes vnc_auto.html to not
automatically find the port as it should.
This simple change checks if window.location.port is blank, and sets port as
appropriate from the name of the protocol in use.
Pull c33f0b52e7 from websockify.
- Fix for python2.4 with URL parsing.
- Set binaryType earlier in Opera 12.10 to avoid receiving a blob.
- Re-order client and target processing so that pending client data
has an opportunity to be sent when the target closes.
Related to issue: https://github.com/kanaka/noVNC/issues/205
Split out the function to load a single script to Util.load_script.
In order to get sequential load, when on IE set the script defer flag.
It is currently working on webkit and firefox but just in case also
set the script.async flag to make sure that scripts execute in the
order they are added. Scripts should still load in parallel.
Data files should now set the variable VNC_frame_encoding to either
"binary" or "base64". The python websockify recording mode adds this
automatically based on what is negotiated with the client being
recorded.
The mobile doctype doesn't not seem to make any difference on iOS so
I'm dropping it and just going with the standard HTML5 version since
the wapforum mobile version may cause issues with IE 10.
Related to issue: https://github.com/kanaka/noVNC/issues/205
Split out the function to load a single script to Util.load_script.
In order to get sequential load, when on IE set the script defer flag.
It is currently working on webkit and firefox but just in case also
set the script.async flag to make sure that scripts execute in the
order they are added. Scripts should still load in parallel.
Related to issue/pulls:
https://github.com/kanaka/noVNC/issues/194https://github.com/kanaka/noVNC/pull/201https://github.com/kanaka/noVNC/pull/202
In IE9, the window.onload event can fire before dynamically loaded
scripts have finished loading. This can result in either WebSocket (in
the case of vnc_auto.html) or RFB (in the case of vnc.html) not being
defined at the point when window.onload is called.
- Move the load_scripts routine from vnc.js to util.js (so that
websockify can use it too). Also, refactor to work when load_scripts
is called by a script that itself uses load_scripts. When the whole
chain of dynamically loaded scripts is finished then call
window.onscriptsload. Use this mechanism in all the places that
depend on dynamic loading of scripts: vnc.html, vnc_auto.html,
websock.js, tests/vnc_playback.html, and tests/vnc_perf.html.
- Use the new window.onscriptsload handler instead of window.onload.
- Remove include/start.js and do the script loading and startup event
handling in include/ui.js instead.
This is a workaround for corrupted non-square cursors seen on some
Windows 7 machines with NVIDIA cards. The corruption only happens when
the screen is in portrait mode.
The MPL 2.0 license is a "file-level" copyleft license vs the
"project-level" nature of the L/GPL. The intention of noVNC has
always been that it should be easy to incorporate into existing
projects and sites whether free/open or proprietary/commercial. The MPL
2.0 is designed for this sort of combination project but still
requires that any distributed modifications to noVNC source files must
also be published under the same license.
In addition, the MPL 2.0 allows the code to be used in L/GPL projects
(the secondary license clause). This means that any projects that are
already incorporating noVNC should not be impacted by this change and
in fact it should clarify the licensing situation (the exact
application of the L/GPL to web applications and interpreted code is
somewhat ambiguous).
The HTML, CSS, image and font files continue to be under more
permissive licenses (see LICENSE.txt). The included websockify python
code remains under a LGPLv3 license although the include/websock.js
file from the websockify component is now under MPL 2.0 as well.
Permission was received from other noVNC authors to make this change to their
code license on the following dates:
- Chris Gordon (UI): Jun 24, 2012
- Antoine Mercadal (DOM,*util.js): Oct 10, 2012
- William Lightning (UltraVNC repeater): Oct 10, 2012
- Mike Tinglof (tight encoding): Oct 15, 2012
Jesper Dam