Use the more specific background-color, and background-image properties
when setting the state backgrounds for the control bar buttons. This way
we no longer pollute all background related properties. It makes things
easier if we need to replace them in some states in the future.
Instead of marking the hover selector with ":not(:disabled)" we can
break out this into its own section. This makes things easier to read.
In order to ensure the correct selector prioritization we also reorder
the file a bit.
Use the more specific background-image property when setting
linear-gradient backgrounds for input elements. This way we no longer
pollute all background related properties. It makes things easier if we
need to replace it in some states in the future.
Some elements used grey text and background when disabled, and some used
opacity. It looked a bit old school to make the elements grey when
disabled. Let's use opacity for all input elements when disabled.
Use the new modern :focus-visible instead of :focus. This is only shown
when navigating using the keyboard.
And in the case of the control bar buttons, This means we can separate
the :focus and :hover styles. Instead of showing a lighter overlay (or
darker for selected) like we use for hover, lets use a more common
blue outline for focus-visible. This also means we can re-use the common
focus-visible from input.css instead of having a special one for control
bar buttons.
The issue with the selection prior to the fix can't be reproduced to
the same degree. It may have been some other bug that caused interaction
with the remote to be blocked.
Since we are setting "appearance: none" on our <select> elements, the
drop down arrow from the browser is hidden. This arrow doesn't fit in
visually though. This commit adds a new arrow from a simple data url
SVG. Its a dark triangle "pointing" downwards.
Note that we need to set the background to both the gradient and the
image here. Both use the "background-image" property for the graphic,
but since they are positioned differently we must use the general
"background" shorthand.
The class "noVNC_button" is only used for control bar buttons. Lets
clarify this in the CSS selectors by only applying styles to elements
with this class that are children of "#noVNC_control_bar".
We thought we already did this in e24b501, but instead we would
basically get random versions as npm would pick some version already
available from whatever was already downloaded.
New attempt, this time being very explicit that we want the version that
has been tagged as "latest".
In order to make the sidebar feel more like a GUI element from a real
application, we can disable the long-press image popup on iOS. Note that
this only has an effect on iOS devices.
When long pressing stuff in the sidebar on iOS, you can sometimes
accidentally select the container or the canvas. This results in a
broken state where the user can't interact with the session anymore.
This commit prevents this from happening.
We want to disable selections in the sidebar because when users drag
the handle, they could otherwise accidentally select stuff. This results
in a very broken state.
When selections are disabled, the sidebar also feels more like a GUI
element from a real application, and less like part of a webpage.
Without this fix we still get a "pointer" cursor on disabled inputs of
type "image" in Firefox. Currently, all our noVNC_buttons are
<input type="image">. Reported to firefox here:
https://bugzilla.mozilla.org/show_bug.cgi?id=1798304
We depend un such modern things anyway, having these kinds of properties
are more confusing than helpful. Let's not give the impression that we
make any attempt to work in old browsers.
The clipboard textarea could potentially shrink further than what was
possible for the header text elements, which looked a bit broken. In
that regard, a min width is introduced for the textarea.
All panels should be limited in this way, not just the clipboard panel.
One additional upside of this is that the numbers used to calculate the
max-width are closer by, in the code. This hopefully makes it easier to
avoid mistakes in the future.
JavaScript strings use UTF-16 encoding under the hood, but we only want
a single '?' per character we replace. So we need to be more careful
which methods we use when iterating over the clipboard string.
Samuel Mannehed
Pierre Ossman
nggit