Previously, Util.getPosition didn't deal with scrolling
particularly well. This fixes that by calculating the
scroll offset when dealing with getting mouse positions.
Credit to @erikgull and @emmar for the initial version of
the fix. Credit to Brian Huismanfor the initial code.
Closes#295
Relevant to #258
Fix keyboard handling for IE10 (issue #352)
* Keyboard events in IE10 do not provide any useful information on the properties 'which', 'char' or 'charCode'. Instead, it seems to store the char code in the keyCode property.
Apparently Firefox on Linux changed the value of navigator.appVersion,
causing our OS detection (used to determine how to interpret different
modifier keys) to fail.
Use navigator.platform instead, which should be more stable.
http://stackoverflow.com/a/19883965/33213
Previously we identified keys in keyboard events by the 'key' property
if it was set, and 'keyCode' otherwise.
This turns out to be problematic as Firefox no longer leaves 'key'
undefined (so we fall back to using 'keyCode'), but instead sets 'key'
to 'MozPrintableKey' for all printable keys.
This meant that when (printable) keys are released, we can't match it
against the corresponding keydown event, and instead just send a keyup
event for the last keydown received.
Now, if both 'key' and 'keyCode' are set, use the concatenation of both.
Otherwise prefer 'keyCode', as that is at least unique for every key.
This should let us release the right keys on keyup events.
When shortcut modifiers (modifier keys such as CTRL, which do not participate in
composing character input) are pressed, we try to suppress the keypress
event, as browsers do not reliably generate it. This means that
subsequent key events are decoded only based on the keydown event.
Due to a type error (comparing a string to a number), shift was
mistakenly treated as a shortcut modifier, preventing text input which
relied on shift, such as _ and %, from being generated.
This allows the keyboard handler to check modifier key state much more frequently
Since some browsers never send keyup events for modifier keys, we have to
synchronize modifier state whenever we get a mouse or keyboard event
Add a node.js-based tool (utils/parse.js) to read keysymdef.h and produce a JavaScript file
mapping Unicode code points to keysyms.
Also add the generated table (include/keysymdef.js).
This patch adds support for the secure attribute on token
cookies (sent by nova-novncproxy). If the https is used
to transfer the cookie, the secure attribute is set thus
restricting server requestes to secure conections only.
This should prevent man-in-the-middle attacks.
button group instead of centered.
* On low resolution devices the padding towards the edges of the screen of
the left and right button groups are now removed.
* Since the status_bar was merged into the control-bar the actual status_bar
element became redundant and was therefor removed.
* Improved the style of the control-bar when there is an error or a warning.
* Implemented a fix so that vnc_auto.html works as intended with the improved
screen real estate patch.
Pull in websockify 4725aa7.
- Update to c0855c6cae of web-socket-js
- Update both the submodule and the swf build. The submodule now
contains the unobfuscated source for swfobject.js which should make
websockify more DFSG compliant.
- Remove Hixie support. iOS 6 now includes HyBi support which means
there is no remaining platform that needs Hixie.
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.
Some browsers (Firefox) reject unencrypted ws connections if the hosting
page uses https by throwing an exception when you create the websocket
object.
NoVNC interprets this as binary being unsupported, and falls back to
base64.
If we instead connect to wss://localhost, the websocket object can be
created regardless of whether the hosting page is on http or https.
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.
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
Instead of using document.write to load scripts, use createElement to
create and append script tags. document.write is problematic in a lot
of situation and in particular is not allowed in a Chrome
extension/packaged app.
Also, in webutil.js, instead of calling init_logging during parsing of
include/webutil.js, rely on the caller to do this. The problem is that
calling init_logging on parse tries to call Util logging functions and
the new model of dynamic load may not having Util loaded by the time
webutil is parsed.
Move all the inline Javascript event handlers from vnc.html to
include/ui.js except the load handler which is moved to
include/start.js). This is on the path towards a Chrome
extension/packaged app since inline Javascript is prohibited in that
situation.
Switch from using cookies to store setting to using localStorage (or
chrome.storage.sync if available in extension/app mode) for the
settings. Also refactor to make the initializing of the setting and
and loading of the UI to be more asynchronous.
Add routines to store/read settings in either localStorage or in
chrome.storage.sync (which is synchronized between browsers for
extensions/apps).
Before using chrome.storage.sync the initSettings routine must to
called setup the intermediate cache which speeds up access and allows
multiple setting changes to be coallesced to avoid hitting storage
change frequency limits/quotas.
- enable sending and receiving of raw array buffers in addition to
strings.
- add a read poll interval and set it to 15ms by default to detect
and handle quickly when a message is pending.
- also, detect a disconnected state and add call registration for
disconnect events.
This change pulls websockify 6d9deda9c5.
Most note worthy changes:
- Pulls in web-socket-js 7677e7a954 which updates to IETF 6455 (from
Hixie)
- Binary support detection and use in include/websock.js
- Add ssl and unix target support
- Add multiple target support via config file/dir.
- Idle timeout exit
Use a simpler method of enabling binary transfer over WebSockets. This
still presents the user of websock.js with a plain javascript array
for the receive queue data. However, if binary support is supported
and requested then the transfer will be raw frames instead of base64
encoded.
Lots of room for optimization here but for now correct is better than
fast.
Pull from websockify 17175afd7311c55abd8d
Pull in version 376872d99.
Several changes including:
- binary/typed array support in websock.js
- unix socket support
- multiple target support via config file(s)
- prefer IPv6 option
Clarify in LICENSE.txt that the noVNC core library is the part that is
LGPLv3 licensed. The HTML, CSS, images and fonts are separate from the
core library and can be modified and distributed with the noVNC core
but under their own license conditions.
HTML and CSS: 2-Clause BSD
Fonts: SIL OFL 1.1
Images: CC BY SA 3.0
In other words, you can modify the layout and appearance of of noVNC
to integrate with an existing or new web site or application without
having to publish the source for those modifications under the LGPLv3.
However, use of and modification of the noVNC core library (i.e. the
core Javascript that makes up noVNC) must still be according to the
LGPLv3.
Chris Gordon was the other contributor to the HTML, CSS, and images
included with noVNC and gave permission for this license clarification
on June 23, 2012.
This will keep copyrect rendering actions in order with tight and tightPNG
rendering actions (otherwise you can get visual image corruption when
they are mixed together).
Warning:
RAW, RRE and HEXTILE still use immediate render commands so there is
still the risk of out-of-order rendering if RAW, RRE, and HEXTILE are
mixed with tight and tightPNG. Copyrect will work with either because
the renderQ_push function will render copyrects immediately if they
are the only thing being pushed on the queue.
The imgQ code in RFB should be a generic rendering queue system in
Display.
The reason for the render queue in the first place is that images
loaded from raw data URI strings aren't immediately ready to display
so we have to wait for them to complete 'loading'. However, when data
URI images are mixed with other types of rendering actions then things
can get out of order. This is the reason for the rendering queue.
Currently this only keeps display actions for tight and tightPNG
related actions in order (because they use a mix of fills, raw pixel
data and data URI images).
This related to https://github.com/kanaka/noVNC/issues/145
The real fix is to QEMU so that this doesn't happen which was
submitted as a patch to the mailinglist right before this.
Fixes https://github.com/kanaka/noVNC/issues/163
When using an encoding with raw images (tight, tightPNG) we need to
draw those image relative to the viewport so that clipping works when
the viewport isn't at 0, 0.
Unfortunately the values for those duplicate keys are not the same and
I'm not sure which ones are more correct. However, for now, I've
commented out the second occurrence.
This data is generated from /usr/include/X11/keysymdef.h using the
utils/u2x11 script.
May window managers have a keyboard shortcut that switch away from the
current desktop (e.g. desktop switcher). Unfortunately, when this
happens, the meta/control keys that are used with the shortcut will
send a down event to the browser, but the up event will never be sent
because the browser no longer has focus at the point when the up event
happens. This can cause weird stuck key issues for VNC clients (not
just noVNC). To get around this, we try and detect when the browser
loses focus and release any keys that are on the keyDownList.
As an aside, if you run into this situation (in noVNC or another VNC
client), you can unstick the state by pressing and releasing the Ctrl,
Shift, Alt, etc.
Addresses: https://github.com/kanaka/noVNC/pull/135
With last_rect, the rects count can be high until a last_rect
pseudo-encoding is received which messes with the timing stats. So
count up the number of pixels rendered and show timing after the pixel
count reaches the width*height of the screen.