This reverts commit 079504a6.

Keyboard altgr

Related to issue/pulls:
https://github.com/kanaka/noVNC/issues/194
https://github.com/kanaka/noVNC/pull/201
https://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.

support ALTGR key event

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

This updated version is imported from:
http://hg.mozilla.org/mozilla-central/raw-file/ec10630b1a54/js/src/devtools/jint/sunspider/string-base64.js

Update to websockify febaeee85c

Gracefully handle errors when popping kwargs:
https://github.com/kanaka/websockify/pull/53

Call setBarPosition on initial load and not just when the window size
changes or scrolling happens.

After a read completes it's possible more data is pending so issue an
immediate read again to pick this up quickly.

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.

Also, include Apache-2.0 license text.

- 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.

Import upstream code from Chrome extension telnet demo:
https://raw.github.com/GoogleChrome/chrome-app-samples/0ce28768087863c08aa04a2b9b27bd50796a77ec/telnet/tcp-client.js

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

Conflicts:
	include/websock.js

For some reason encode_message was missed. But I'm just punting and
doing the fixup in the merge. Yeah, tsk, tsk.

Push master and version tag separately.

Instead of continuing to maintain the full list of project/companies
that use noVNC in multiple places (README, wiki, web page) just link
to the wiki page.

Link to noVNC discussion group page. Link to issues page. Link to
Amazon wishlist and non-profits for appreciation.

Instead of continuing to maintain the full list of project/companies
that use noVNC in multiple places (README, wiki, web page) just link
to the wiki page.

Link to noVNC discussion group page. Link to issues page. Link to
Amazon wishlist and non-profits for appreciation.

Fix grep pattern when matching netstat output

The current grep pattern matches also port numbers that match only
partially the given $PORT number; e.g., if $PORT is 6080, 60800 will
match as well.

While TCP listening sockets in the 60000-65535 range are rare, they
need to be handled as well. The problem is also present if the user
selects a shorter PORT value with the --listen command line argument.

By adding a space, the pattern is fixed.

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

This reverts commit 4dd1bb1e.

This reverts commit 14717eb4.

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

With tight we can't ever use FBU.rects being 0 as an indication of
a full frame having been drawn.