When a touch screen is available, like on many laptops or most Chromebooks, the buttons in the control bar doesn't react to mouse hover. This doesn't feel very polished.
Things have moved a bit here after changes made under bug 7908. But the problem that devices with both touch and mouse doesn't get :hover effects remain. (In reply to Samuel Mannehed from comment #1) > You can't hover normally with only a touch screen. However, after touching > on a button, the :hover state in CSS will be active until you touch > somewhere else. > > We assume this code was once added because browsers on Android didn't ever > remove the hover after clicking in the session. This likely happened > because, as described in the code comment, we intercepted all touch events > to send as mouse clicks to the ThinLinc server. > > My testing shows that the situation has changed here. Nowadays, the hover > state is released after tapping in the session. This means we can remove > these ":root:not(.noVNC_touch)" parts and greatly simplify a lot of the CSS > selectors we have. This is partly false. I was probably confused by :focus. When retesting this, the :hover state remains even after tapping in the session. > A consequence of these complicated selectors in noVNC's base.css is that our > selectors in thinlinc.css are even more complicated since we want to do > things differently. We could get rid of parts of the complicated selectors (and the FIXME) since we moved away from using :focus (in favor for :focus-visible).
As mentioned before, we need to prevent :hover on touch-only devices is because otherwise it leaves a :hover effect behind after tapping buttons. One thing that increases the significance of this issue is that the lingering :hover can be confused with selected buttons in the control bar.
As part of bug 7908 we split styling for buttons into a CSS file intended to be shared between Web Access, Web Admin, the TAG and even cendio.com. However, the method we use to disable :hover on touch devices relies on JavaScript from noVNC. This means we can't use the shared CSS like we would want. For this reason, we have decided to find a more general solution that doesn't rely on noVNC. That solution will be very related to this bug, so let's see if this can be resolved at the same time.
Unfortunately, the CSS media queries that were our idea here does not allow us to fully fix this bug. There are rules that allow us to detect if a touch screen is available (any-pointer: coarse), or if the primary input device can hover (hover: hover), but these are mostly static. There are no adaptive selectors that changes depending on the latest input method. Currently, this is only possible using JavaScript. Here are some extensive test results regarding these media queries in different browsers on different devices: https://patrickhlauke.github.io/touch/pointer-hover-any-pointer-any-hover/results/ Because we were able to resolve the issue regarding sharing input.css without fixing this bug, we will leave this bug for another time.
A solution to this bug could be possible if something like a “:hover-fine” selector was implemented: https://github.com/w3c/csswg-drafts/issues/7544 One thing to note as well is that the media query “hover: hover” doesn't work on Samsung Android devices. Samsung always reports that a “fine” pointer that is capable of “hover” is available. See these bug reports: https://bugs.chromium.org/p/chromium/issues/detail?id=1349071 https://bugs.chromium.org/p/chromium/issues/detail?id=940256
