Non-Native UI buttons are missing a click indication
Categories
(Core :: CSS Parsing and Computation, defect)
Tracking
()
People
(Reporter: allo, Unassigned)
Details
Attachments
(5 files)
The default style for the non-native UI widgets is missing some features of native UI.
The most annoying part is that the default button does not have any indication on mousedown. A normal button has some "is pressed" state when you're holding down the left mouse button, which shows that releasing the button will trigger the onclick event. Moving the mouse outside of the button shows the button as not pressed again showing that no onclick event will be fired when release the mouse button.
Another issue I noticed is that the standard combo box (e.g. <select size="1">) is missing the down arrow to the right and looks exactly like a button.
Both also feature only a minimal hover effect changing the border almost not noticeable from dark gray to black (or a darker gray). This is also bad for accessibility.
Added a screenshot of a combo box and a button that look the same and do not have noticeable UI effects when using them.
Hi alex,
What Linux distro and window manager are you using?
Debian Testing, KWin X11 (KDE) and Gtk-Theme Clearlooks-Phenix* (but it probably doesn't matter anymore wie non-native UI).
(In reply to alex from comment #3)
Not sure if it is the right repo for the theme (as the latest commit in that repo is from 2016). I am using the distro version.
Can you please add the exact steps to reproduce this issue in order to try and reproduce it in our side?
Thanks,
Victor
There are no special steps.
- Create a file with content "<input type=button value=test><select><option>test</option></select>"
- Open the File with Firefox 99
- Observe the barely noticeable hover effect and the missing "pressed" indiction when clicking the button.
Expected result:
- The button should have a clear indication that it is pressed (e.g. inverted outline shape)
- The hover effect should be much more visible (compare with e.g. Gtk or Qt themes)
Action result:
- No effect when clicking and holding the button
- a barely visible color change (darkgray to black or a darker gray) of the border of the elemente onmouseover.
An example how a button (left) looks when pressing and holding the left mouse button (right) in Gtk.
You can see a clear change in color and (probably easier to see when trying it interactively) the slight 3D effect changes from a button that is over the surface to a button that is pressed below the surface of the UI.
I have only Ubuntu 18.04.2 LTS and I was not able to reproduce the issues described above with only one exception . I can confirm that " Moving the mouse outside of the button shows the button as not pressed again showing that no onclick event will be fired when release the mouse button."
I will attach a screenshot describing the behavior for hovering and left click and hold on my side.
Also I was not able to reproduce the issue on Windows 10x64
Thanks,
Victor
| Reporter | ||
Comment 10•3 years ago
|
||
This looks way more usable than on my system. I wonder what's the difference and what system properties Firefox uses for non-native widgets. I would have expected that they do not follow the system, but on the other hand look the same on every system.
Still I can reproduce the problem with a completely fresh Firefox:
$ export HOME=/tmp/emptyhome
$ firefox test.html
gives me a Firefox that uses default settings for everything (e.g. menus use the default Gtk theme instead of my configured one, etc.), but still has the missing effects on the buttons.
I wonder if it is a bug in the Debian (testing) packages or what other system properties are used by Firefox to control how the buttons are rendered.
Comment 11•3 years ago
|
||
I am not sure about the Debian packages , but I can confirm that I always use fresh installations and default settings for Firefox when trying to reproduce issues.
Thanks,
Victor
Comment 12•3 years ago
|
||
The severity field is not set for this bug.
:dao, could you have a look please?
For more information, please visit auto_nag documentation.
| Reporter | ||
Comment 13•3 years ago
|
||
I found out how to reproduce it:
The buttons are missing the click and hover effects, when the now obsolete preference "widget.non-native-theme.enabled" is true.
Comment 14•3 years ago
|
||
Hello,
I tried reproducing the issue on the latest Nightly (104.0a1/20220629215821), Beta (103.0b2/20220628190840) and Release (102.0/20220623063721) under Ubuntu 16.04 LTS with the "widget.non-native-theme.enabled" pref set to “true” (this is the default value) and using a .html file with the contents specified in Comment 6, however without success.
I obtained the same results as in the screenshot from Comment 9:
- on hover, the button becomes grayer
- on click and hold, the button turns a much darker shade of gray
On the other hand, setting the above pref to “false”, will cause the button to behave more like what you described i.e. there is no color change when hovering or clicking and holding the button. The only difference I managed to observe is that the outline of the button becomes more pronounced (darker) on hover and more so when clicking and holding the button. See the attached screenshot.
I’ve also tested Firefox 99 and obtained the exact same results as above:
- proper hover and click effects with the pref set to true
- no effects beside the more pronounced outline, with the pref set to false
Comment 15•3 years ago
|
||
Updated•2 years ago
|
| Reporter | ||
Comment 16•2 years ago
|
||
With Firefox 112 on Linux I currently see a quite good effect when the button is pressed and held.
I think it works for me, but I am not sure if it now works on all systems or depends on themes, settings or other things.
| Reporter | ||
Comment 17•2 years ago
|
||
Sorry, I overlooked that it also depends on the setting. With the setting set to false it does not work.
Comment 18•2 years ago
|
||
The severity field is not set for this bug.
:jfkthame, could you have a look please?
For more information, please visit BugBot documentation.
Comment 19•2 years ago
|
||
It sounds to me like this is WFM provided non-native theme is enabled, which is the default, but there may be an issue if the pref is disabled. Emilio, is that something we should care about at this point, or is it basically no longer supported?
Comment 20•2 years ago
|
||
No, we don't want to support disabling the non-native theme in content in practice. On Linux in particular we don't even load GTK on child processes so we can't render native widgets anymore.
Description
•