Some functions weren't obvious what they would do if an argument was
omitted. Split them up in to separate functions in those cases to
make the API clearer.
The panels were never meant to be positioned relative their container,
so make sure they pop up exactly where we want in the viewport, no
matter where they are in the structure.
According to the RFB protocol, when in TIGHT auth negotation,
if the client receives a sub-auth count of zero, it should proceed
as if the `None` sub-auth type had already been selected (and not
send a message selecting that type).
Closes#564
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.
Added a 'QEMUKeyEventDecoder' method to deal with the
key events generated when the QEMU extension is active. Another
method, 'TrackQEMUKeyState', was also created with this same
goal.
Although both methods have similaries with the existing methods
'KeyEventDecoder' and 'TrackKeyState', specially when dealing
with 'supress' and 'releaseall', the logic behind the QEMU extension
does not required keysym generation for most cases (some NumPad keys
are an exception) and, as such, there is no need to treat 'keyPressed'
events and to handle char modifiers.
'TrackQEMUKeyState' also handles a Windows scenario where the
'AltGR' key generates CtrlLeft and AltRight keystrokes. The solution
was to avoid this specific combination to be sent to the VNC server,
discarding the extra 'CtrlLeft' key. Considering that the user can
send CtrlLeft+AltLeft, CtrlRight+AltRight and even CtrlRight+AltLeft,
this workaround to allow Windows users to use AltGR in their noVNC
sessions is worthwhile.
Signed-off-by: Daniel Henrique Barboza <danielhb@linux.vnet.ibm.com>
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.
samhed
Pierre Ossman
Dmitry Sankevich
Solly Ross
Lars Ole Hurlen
Solly Ross
Daniel Henrique Barboza
Trần Tuấn Anh