Open
Bug 1309750
Opened 9 years ago
Updated 3 years ago
Widget-generated focus outline colors on HTML <button> elements sometimes lack contrast with the widget-provided background color for buttons (dependent on GTK theme)
Categories
(Core :: Widget: Gtk, defect, P5)
Tracking
()
UNCONFIRMED
People
(Reporter: jidanni, Unassigned)
References
()
Details
(Whiteboard: tpi:+)
Attachments
(1 file)
|
1.29 KB,
image/jpeg
|
Details |
User Agent: Mozilla/5.0 (X11; Linux i686; rv:50.0) Gecko/20100101 Firefox/50.0
Build ID: 20160925011120
Steps to reproduce:
Visit https://www.ptt.cc/ask/over18?from=%2Fbbs%2FBDSM%2Findex.html then hit TAB several times.
Actual results:
Can't tell which button is currently active.
If one disables the black background, (ALT V y n) it is easier to tell.
Otherwise one must look VERY carefully.
Expected results:
It should be easier to tell which button we have currently TABed to.
| Reporter | ||
Updated•9 years ago
|
Component: Untriaged → Disability Access
Comment 1•9 years ago
|
||
Question is if this is our bug, or if the website author needs to change focus visibility. Anyway, changing to the Theme component for now. Gijs, can you take a look, please?
Component: Disability Access → Theme
Flags: needinfo?(gijskruitbosch+bugs)
Comment 2•9 years ago
|
||
Bugs with website styling are never a Firefox::Theme bug. They're either bugs with the website or bugs with how layout does focus styling on web content.
Layout uses system colors for button backgrounds and focus ring styling by default, and the website does not override them.
This looks fine on my Linux theme as well as Windows 10. Dan, can you provide a screenshot?
Component: Theme → Untriaged
Flags: needinfo?(gijskruitbosch+bugs) → needinfo?(jidanni)
| Reporter | ||
Comment 3•9 years ago
|
||
1. I am saying this is a bug for the disabled users counting on hitting
the TAB key in lieu of using the mouse, to navigate the page.
2. Please open a new private window and browse the page.
Please confirm that five(5) presses of TAB will complete a full
cycle, putting focus back where you were, (e.g., URL bar, which becomes
blue (very clear!! THANK YOU.) each time.
3. Now try to figure out how many TABs it takes to reach the first big
button of the two at the bottom of the page.
Yes, one more TAB will put one on the second button.
How to make sure which button we are on?
Well here's the image you wanted:
I did ALT V y n to turn off styles (optional),
and did CTRL++++++++ as much as I could.
And, if you finally zoom the JPG, you will see the faint dashed line
showing indeed which button we are currently "on".
BUT 99.9% of the general public CANNOT see that good.
Flags: needinfo?(jidanni)
| Reporter | ||
Comment 4•9 years ago
|
||
In fact we also notice the buttons are of a slightly different color.
This must be due to my mouse movements to make the screenshot.
Comment 5•9 years ago
|
||
(In reply to Dan Jacobson from comment #3)
> Created attachment 8800600 [details]
> f.jpg
>
> Well here's the image you wanted:
>
> I did ALT V y n to turn off styles (optional),
>
> and did CTRL++++++++ as much as I could.
>
> And, if you finally zoom the JPG, you will see the faint dashed line
> showing indeed which button we are currently "on".
>
> BUT 99.9% of the general public CANNOT see that good.
I'm afraid my point must not have been very clear. The background color of that button is determined by your Linux theme, as is the exact color of the focus outline, I think. On mine, the contrast of that background with the dashed focus outline is much better. On Windows 10, I even get an additional blue outline outside of the button. Yours seems to be using almost the same shade of grey. I agree that's wrong. I don't know how easy it is to fix.
I looked at forms.css for a bit, which does a bunch of our form control styling. It seems to try to use buttontext for the border-color. I tried using 'red' instead, but that doesn't seem to actually affect the styling, unless I manually change the background: property of the button. AIUI this means that the current styling is provided by the -moz-appearance value instead, which means this is a GTK widget bug. Karl?
Component: Untriaged → Widget: Gtk
Flags: needinfo?(karlt)
Product: Firefox → Core
Updated•9 years ago
|
Summary: cannot tell current button due to background color → Widget-generated focus outline colors on HTML <button> elements sometimes lack contrast with the widget-provided background color for buttons (dependent on GTK theme)
| Reporter | ||
Comment 6•9 years ago
|
||
Well I suppose I shouldn't complain about the colors of the buttons.
Else the big blue "Save Changes" button on this bug report couldn't be
blue etc.
I would just like to complain about that FAINT dashed line. Could it be
please made more obvious?
I'm sure the faint dashed line is part of Firefox and not some part of
X-windows etc.
Comment 7•9 years ago
|
||
(In reply to Dan Jacobson from comment #6)
> Well I suppose I shouldn't complain about the colors of the buttons.
> Else the big blue "Save Changes" button on this bug report couldn't be
> blue etc.
Bugzilla itself styles that button. The site you're having this issue with does not style its <button> at all. You're seeing the styling provided by Firefox.
> I would just like to complain about that FAINT dashed line. Could it be
> please made more obvious?
Yes, I got it the first 2 times. It's a hard problem to solve, believe it or not, to make that line always "work".
> I'm sure the faint dashed line is part of Firefox and not some part of
> X-windows etc.
Firefox renders the line, yes, and the rest of the button. At least for some of those colours, Firefox asks your GTK theme to provide. This is why things like buttons and checkboxes on HTML pages *can* look just like buttons in 'native' applications, if the website does not override anything. I expect we're either not asking GTK for the right thing or there are other things we should ask for to get the right focus styling (e.g. a change in background color/gradient or whatever). Karl will know more.
Comment 8•9 years ago
|
||
(In reply to :Gijs Kruitbosch (out until Monday) from comment #5)
> I looked at forms.css for a bit, which does a bunch of our form control
> styling. It seems to try to use buttontext for the border-color. I tried
> using 'red' instead, but that doesn't seem to actually affect the styling,
> unless I manually change the background: property of the button. AIUI this
> means that the current styling is provided by the -moz-appearance value
> instead,
Yes, that's what I'd expect and that's what seems to be happening.
The screenshot look like the default GTK theme, Adwaita.
Running gtk3-widget-factory, making its window active, and typing tab a few times renders the same focus outline on buttons, in the same color.
Oddly enough the "HighContrast" theme also does not provide a high contrast focus outline.
Clearlooks-Phenix and Ambiance provide much more contrast, though even these can be hard to see with the dark background color. The expectation is that, if a page chooses a dark background, then it will also choose its own suitable styles for the widgets.
I guess it might be possible for Firefox to sometimes detect dark backgrounds and if found present a different styling for widgets, but detecting a dark background is not always practical with the possibility of any content under the widgets.
Flags: needinfo?(karlt)
Priority: -- → P5
| Reporter | ||
Comment 9•9 years ago
|
||
Trying to detect backgrounds will only get us into more trouble.
Can't the dotted line be made thicker?
Comment 10•9 years ago
|
||
GTK draws the dotted line and so Gecko doesn't define the thickness.
The dotted line thickness can be configured by adjusting the CSS for the GTK theme. That can be done in user or system config files.
Updated•9 years ago
|
Whiteboard: tpi:+
Updated•3 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•