When you navigate through the in-content preferences you will notice that there is no focus rect drawn at all for elements except buttons and textboxes. So you navigate mostly blindly through them. Also checkboxes and radio buttons have a style which visualizes that those are always focused. Means the blurred blue border gives a wrong information to the user.

I’d also vote for leaving the blurred outline exclusive for `:focus`, because it in addition to reasons presented by :whimboo it: 1. is too visually taxing, especially in pages which contain a lot of elements styled this way; 2. doesn’t fit Firefox look&feel nor it does fit any of OSes look&feel.

(In reply to Henrik Skupin (:whimboo) from comment #0) > Also checkboxes and radio buttons have a style which visualizes that those > are always focused. Means the blurred blue border gives a wrong information > to the user. That part is actually bug 996036. So please not focus on it here.

Besides buttons and textboxes, where should focus rects be drawn? Bug 1014698 covers the categories.

For elements as used in about:preferences I do not see a focus on the following elements: * drop down boxes * checkbox * radio button

(In reply to Henrik Skupin (:whimboo) from comment #4) > * checkbox > * radio button For these, focus rings should be on the labels.

(In reply to Dão Gottwald [:dao] from comment #5) > (In reply to Henrik Skupin (:whimboo) from comment #4) > > * checkbox > > * radio button > > For these, focus rings should be on the labels. Why that? Do content elements behave differently than elements in chrome? For the latter I definitely don't see focus rings around the label but the element itself.

On OS X, buttons don't have a focus ring either.

(In reply to Dão Gottwald [:dao] from comment #5) > (In reply to Henrik Skupin (:whimboo) from comment #4) > > * checkbox > > * radio button > > For these, focus rings should be on the labels. Not on OS X.

Marking David as the QA contact for this bug for him to verify the fix after it has landed.

This could be a good first bug when we get proper specs from the UX team.

Michael, do we have specs for the focused state ?

(In reply to Tim Nguyen [:ntim] from comment #15) > Michael, do we have specs for the focused state ? Looks like we do : http://cl.ly/image/1T3a070b3E28 The color used for the outline is rgba(0,149,221,0.5) (corresponds to #0095DD 50%). Here's how this bug can be fixed : - In toolkit/themes/shared/in-content/common.inc.css, use the :-moz-focusring pseudo class to target the focus state. You'll add the outline styles for the checkbox, radio, and buttons. Here's the CSS you can use : outline: 3px solid rgba(0,149,221,0.5); outline-offset: 2px; -moz-outline-radius: /*border radius*/;

This is too difficult to be a good first bug. There are many different control types: - radio buttons - checkboxes - input boxes - menulists - buttons - lists - trees ... that all need various types of fixing, even where the styling already exists (e.g. it wfm on Windows nightly right now, but does weird things with the padding when tabbing through the download pref, for instance). (In reply to Tim Nguyen [:ntim] from comment #17) > (In reply to Tim Nguyen [:ntim] from comment #15) > > Michael, do we have specs for the focused state ? > > Looks like we do : http://cl.ly/image/1T3a070b3E28 > > The color used for the outline is rgba(0,149,221,0.5) (corresponds to > #0095DD 50%). That won't work well with high contrast themes. Why can't we just use greytext? > Here's how this bug can be fixed : > - In toolkit/themes/shared/in-content/common.inc.css, use the > :-moz-focusring pseudo class to target the focus state. You'll add the > outline styles for the checkbox, radio, and buttons. As noted above, that's not enough. > Here's the CSS you can use : > > outline: 3px solid rgba(0,149,221,0.5); > outline-offset: 2px; Why do we need a 2px offset?

(In reply to :Gijs Kruitbosch from comment #18) > This is too difficult to be a good first bug. There are many different > control types: > > - radio buttons > - checkboxes > - input boxes > - menulists > - buttons > - lists > - trees > ... > > that all need various types of fixing, even where the styling already exists > (e.g. it wfm on Windows nightly right now, but does weird things with the > padding when tabbing through the download pref, for instance). - Input boxes don't need a fix, the border already turns blue (except for high contrast, but that's not what this bug is about). - Radios, checkboxes, buttons, menulists and buttons are handled here. - The tree and richlistbox cases have been handled by making the border dotted. Taking care of the listbox elements is fairly easy. - Links are already handled, either by the outline on windows, either by the underline on OSX. - Tabs and categories seem already handled by outlines. > (In reply to Tim Nguyen [:ntim] from comment #17) > > (In reply to Tim Nguyen [:ntim] from comment #15) > > > Michael, do we have specs for the focused state ? > > > > Looks like we do : http://cl.ly/image/1T3a070b3E28 > > > > The color used for the outline is rgba(0,149,221,0.5) (corresponds to > > #0095DD 50%). > > That won't work well with high contrast themes. Why can't we just use > greytext? Linux and windows high contrast themes can use threeDShadow or ThreeDLightShadow. > > > Here's how this bug can be fixed : > > - In toolkit/themes/shared/in-content/common.inc.css, use the > > :-moz-focusring pseudo class to target the focus state. You'll add the > > outline styles for the checkbox, radio, and buttons. > > As noted above, that's not enough. > > > Here's the CSS you can use : > > > > outline: 3px solid rgba(0,149,221,0.5); > > outline-offset: 2px; > > Why do we need a 2px offset? There's a 2px offset in the mockup.

Hey Tim, Jared and I were discussing this bug and were wondering if you would be willing to fix it yourself rather than mentoring someone else?

Windows/Linux still need the padding fixes for focus on e.g. the downloads part of the general pane, and I don't think they currently have the 2px offset for buttons, trees and links (at a minimum, not checked everything) that comment #19 mentions.

Well, I'm currently on holiday, so luckily I have some time. This is an OSX only issue it seems. Anyway, this takes care of the buttons, the radios and the checkboxes. The trees and listboxes already have an outline on focus (bug 1017967). I couldn't think of any more elements left in the UI to fix. Also, I've only tested this by pasting the code into the style editor on Windows, I don't have OSX to test properly.

Comment on attachment 8568809 [details] [diff] [review] Patch Whoops, this patch has unrelated stuff in it.

Patch without unrelated changes

Comment on attachment 8568812 [details] [diff] [review] Patch v1.1 Review of attachment 8568812 [details] [diff] [review]: ----------------------------------------------------------------- I'm assuming you're planning to fix the issues with the Linux/Windows styling (2px away from the button/label/whatever; elements moving as focus moves through the document) in a separate patch? ::: toolkit/themes/osx/global/in-content/common.css @@ +83,5 @@ > text-decoration: underline; > } > + > +xul|button:-moz-focusring, > +xul|menulist:-moz-focusring, Is there a design for the focused tabs on the Advanced pane? If not, this should just include xul|tab:-moz-focusring > .tab-middle > .tab-text, here for now (parity with Windows), and we can iterate if necessary.

(In reply to :Gijs Kruitbosch from comment #25) > Comment on attachment 8568812 [details] [diff] [review] > Patch v1.1 > > Review of attachment 8568812 [details] [diff] [review]: > ----------------------------------------------------------------- > > I'm assuming you're planning to fix the issues with the Linux/Windows > styling (2px away from the button/label/whatever; elements moving as focus > moves through the document) in a separate patch? Yeah, fixing the Windows/Linux styling is something else that we can take care of later. Let's stick for the dotted outline for now, and we can polish things later. Filed bug 1136645. > ::: toolkit/themes/osx/global/in-content/common.css > @@ +83,5 @@ > > text-decoration: underline; > > } > > + > > +xul|button:-moz-focusring, > > +xul|menulist:-moz-focusring, > > Is there a design for the focused tabs on the Advanced pane? If not, this > should just include > > xul|tab:-moz-focusring > .tab-middle > .tab-text, > > here for now (parity with Windows), and we can iterate if necessary. I don't think there's one. Will include that in my next patch.

I was able to reproduce this issue on Firefox 34.0a1 (2014-08-18) using Ubuntu 12.04 32bit and Mac OS X 10.9.5. I verified this bug on Latest Firefox 39.0a1 (2015-03-11) using Ubuntu 12.04 32bit, Mac OS X 10.9.5 and Windows 7 64bit and this is what I have noticed: 1. Ubuntu 12.04 32bit - this issue is reproducible: tabs, drop-down boxes, checkboxes and radio buttons are not focused. 2. Mac OS X 10.9.5 - all the elements are focused. 3. Windows 7 x64 - all the element are focused. I made a comparison between Mac and Windows and I observed an inconsistency: the element itself is focused on Mac (e.g http://i.imgur.com/JsVk8sm.jpg ) while on windows, for checkboxes and radio buttons, the focus rings are around the labels (e.g http://i.imgur.com/RQOhyKj.jpg ). Is this the expected behavior for each platform? Based on the above mentions should I reopen this bug or file separate ones?

(In reply to Vasilica Mihasca, QA [:vasilica_mihasca] from comment #30) > I was able to reproduce this issue on Firefox 34.0a1 (2014-08-18) using > Ubuntu 12.04 32bit and Mac OS X 10.9.5. > > I verified this bug on Latest Firefox 39.0a1 (2015-03-11) using Ubuntu 12.04 > 32bit, Mac OS X 10.9.5 and Windows 7 64bit and this is what I have noticed: > > 1. Ubuntu 12.04 32bit - this issue is reproducible: tabs, drop-down boxes, > checkboxes and radio buttons are not focused. That's weird, are you using the keyboard to focus them ? If so, it should be handled by bug 1136645. > 2. Mac OS X 10.9.5 - all the elements are focused. > 3. Windows 7 x64 - all the element are focused. > > I made a comparison between Mac and Windows and I observed an inconsistency: > the element itself is focused on Mac (e.g http://i.imgur.com/JsVk8sm.jpg ) > while on windows, for checkboxes and radio buttons, the focus rings are > around the labels (e.g http://i.imgur.com/RQOhyKj.jpg ). > > Is this the expected behavior for each platform? This will be handled by bug 1136645.

(In reply to Tim Nguyen [:ntim] from comment #31) > That's weird, are you using the keyboard to focus them ? I confirm that I used the keyboard to focus the elements. > If so, it should be handled by bug 1136645. > This will be handled by bug 1136645. Marking this bug verified since the other issues are tracked separately.

Comment on attachment 8569181 [details] [diff] [review] Patch v2 Approval Request Comment [Feature/regressing bug #]: n/a [User impact if declined]: no visible focus in in-content prefs on OS X [Describe test coverage new/current, TreeHerder]: nope [Risks and why]: low, css-only change on OS X [String/UUID change made/needed]: nope

Verified fixed on Firefox 40.0a1 (2015-04-05), Firefox 39.0a2 (2015-04-05) and Firefox 38 Beta 1 (20150330154247) using Windows 7 64-bit, Mac OS X 10.9.5. The issues mentioned in comment 30 are still present, but as Tim mentioned, these will be handled by bug 1136645 .