The previous attempt could leave parts of the canvas outside the
document, making it impossible to reach. Use a safer method as
recommended by Mozilla.
Retire the old settingsApply. This also allows UI logic to check the
state of things using the settings instead of having to look at the
values of HTML elements (we couldn't be sure if the changes were
applied yet or not).
It stopped working when we switched to textContent as it relies
on being able to add new HTML elements. Do things properly by
adding new elements via createElement().
Previously, setting `innerHTML` was used to display the statuses. These
could include content communicated from the remote VNC server, allowing
the remove VNC server to inject HTML into the noVNC page.
This commit switches all uses of `innerHTML` to use `textContent`, which
is not vulnerable to the HTML injection.
We don't have to check for _display or context here since this is a
private function which is never called under such circumstances. This
solves problems caused by display.get_context() which was previously
removed in e549ae074f.
We have enough layers now that we need to have some system for this.
E.g. make sure that dialogs during connect show up in front of the
blocking transition layer.
Anyone with basic knowledge of CSS will easily figure out how to
customise the appearance of the UI, so remove the burden of having
to maintain these extra style sheets.
The old default was to ask for the maximum compression level. This
is against the recommendations in libvncserver/tight.c due to excessive
CPU load. It also causes Vino 3.8.1 (still shipped with Ubuntu 16.04
LTS) to prefer the blurry JPEG compression too much - e.g. red text on
the default background in MATE terminal becomes almost unreadable.
The new default is the recommended compression level for low-color
workloads, according to libvncserver source. Also, it is the maximum
compression level that doesn't trigger the Vino bug with red text in
most cases.
Fixes issue #737.
Do all rendering to a hidden canvas and then copy over the finished
frame to the visible canvas once everything is done. This simplifies
things and solves some bugs as we can retain a copy of the entire
frame buffer.
setTimeout() is subject to delays, possible massive ones. As such it
is rather useless for performance sensitive code. Use the non-standard
setImmediate() API instead, emulating it on postMessage() when it
isn't available.
The hacks needed to run these tests require proper handling of
properties. Unfortunately IE and old versions of Chrome mess up,
so just skip the tests there.
Pierre Ossman
Samuel Mannehed
Alexander Neumann
Solly Ross
Solly Ross
Alexander E. Patrakov
Lee-Feng