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
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.
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.
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
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
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.
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.
Conflicts:
include/display.js
include/rfb.js
This merges in the fix for https://github.com/kanaka/noVNC/issues/70
This changes noVNC to use the preferred color ordering that most VNC
server prefer and that VMWare VNC requires. It's possible this may
break some VNC servers out there in which case we might have to do
something a bit more subtle such as having alternate render functions
for little and big endian color ordering.
Issue: https://github.com/kanaka/noVNC/issues/118
Reporter @maxnet also found and suggested the fix.
Probably could be more intelligent/generic by keying off the depth
sent by the server, but this will do for now.
Resolve issue: https://github.com/kanaka/noVNC/pull/101
Based on proposal from @mightpenguin:
Matthew Balman <emperor@mightypenguin.org>
If view_only option is set then do not send mouse and keyboard events.
This is not a secure/enforced way to make a client view only. To
enforce view only at the server, most VNC servers support setting
a view only password.
