1273904 - Browser console has an odd focus style

Status: RESOLVED FIXED

(DevTools :: Console, defect)

Description

[:Gijs (he/him)]

There's a light-blue 2px line at the bottom of the field that animates in whenever it gains focus, including when you alt-tab to the window, which looks like it's basically just a rendering glitch and is a bit distracting. Can we come up with something that is less distracting? :-)

Comment 1

[Yura Zenevich [:yzen] (please use "needinfo")]

Hi Helen, let me know what you think and if you would want me to revisit this?

Comment 2

[Brian Grinstead [:bgrins]]

It was an alternate UI for the initial focus states, which was a blue box shadow around the whole element.  Now that we switched to a more traditional focus style throughout the toolbox we could consider falling back to that for the console input.

Comment 3

[Yura Zenevich [:yzen] (please use "needinfo")]

I'm alright with dotted outline if that's what you mean, Brian

Comment 4

[Helen V. Holmes (:helenvholmes) (:✨)]

(In reply to (Unavailable until May 23) Brian Grinstead [:bgrins] from comment #2)
> It was an alternate UI for the initial focus states, which was a blue box
> shadow around the whole element.  Now that we switched to a more traditional
> focus style throughout the toolbox we could consider falling back to that
> for the console input.

I'd be all right with that. Yura, you fine with revisiting this?

Comment 5

[Yura Zenevich [:yzen] (please use "needinfo")]

Attachment: MozReview Request: Bug 1273904 - reverting webconsole blue focus highlight to dotted outline. r=bgrins

Review commit: https://reviewboard.mozilla.org/r/54270/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/54270/

Comment 6

[Brian Grinstead [:bgrins]]

Comment on attachment 8754834 [details]
MozReview Request: Bug 1273904 - reverting webconsole blue focus highlight to dotted outline. r=bgrins

https://reviewboard.mozilla.org/r/54270/#review50966

Code changes work for me.  It appears the right side of the outline is cut off / not visible, but I don't see an easy way around that

Comment 7

[Yura Zenevich [:yzen] (please use "needinfo")]

I tried looking into this and it seems like the outmost chrome window has a border or something that overlaps by 1px :S

Comment 8

[arni2033]

(In reply to (Unavailable until May 23) Brian Grinstead [:bgrins] from comment #2)
> It was an alternate UI for the initial focus states, which was a blue box shadow around the whole
> element.  Now that we switched to a more traditional focus style throughout the toolbox we could
> consider falling back to that for the console input.
Currently, all input fields in devtools have blue outline when they're focused with keyboard (except
DOM inspector mentioned in bug 1273345). They all also blink and look like rendering glitch when I switch to firefox window with Alt+Tab. They are also distracting and too shiny as said in comment 0.

So why are you going to break that input with ugly dotted outline which is _never_ used for input fields? You're going to always show that dotted outline in unusual place to users who don't even use Tab key for navigation (and probably hate all occurences when useless dotted focusring appears).
Why do you break this intentionally? And how about all other blinking input fields?

Comment 9

[Helen V. Holmes (:helenvholmes) (:✨)]

(In reply to arni2033 from comment #8)
> Currently, all input fields in devtools have blue outline when they're
> focused with keyboard (except
> DOM inspector mentioned in bug 1273345). They all also blink and look like
> rendering glitch when I switch to firefox window with Alt+Tab. They are also
> distracting and too shiny as said in comment 0.
> 
> So why are you going to break that input with ugly dotted outline which is
> _never_ used for input fields? You're going to always show that dotted
> outline in unusual place to users who don't even use Tab key for navigation
> (and probably hate all occurences when useless dotted focusring appears).
> Why do you break this intentionally? And how about all other blinking input
> fields?

Hey arni2033,

This is part of a intended move toward making FF developer tools more accessible. That said, we're open to feedback on how we might improve the UI. Any ideas on how we might do that?

Comment 10

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/1663fc366770

Comment 11

[arni2033]

(In reply to Helen V. Holmes (:helenvholmes) (:✨)(pls ni?) from comment #9)
> This is part of a intended move toward making FF developer tools more accessible.
Well, this bug in fact doesn't improve anything functional. It only changes styling, to the worst.

> Any ideas on how we might improve the UI?
The first and the most important thing is to always use logic. Or use traditional style. Or at least ask Shorlander how he feels about drawing dotted outline from the 90-s on a single input field.
"Traditional focus style" from comment 2 never suggested dotted outline on <input>. Traditional style for <input> is almost no highlight, because blinking caret is enough for detecting it.

I'll start with a possible solution for version 2016-05-25 and then explain why current approach is illogical. CSS that makes console consistent with any other inputs with "highlight for accessibility":

--theme-focus-box-shadow-inset-bottom: 0px 0px 0px 1px var(--theme-highlight-blue) inset !important;

Once you apply said CSS, console doesn't differ from any other field with shiny blue highlight.
Therefore comment 0 would be invalid, or could be applied to ANY other field with highlight, and
EITHER no patch is required OR the patch should "fix" all such blinking inputs at once.

So, current patch is illogical: it was said that it implements traditional focus style, but implements
something completely different. In addition it leaves unused CSS var --theme-focus-box-shadow-inset-bottom. If somebody reported a bug about another blinking input in _the_same_ manner as comment 0, how would you react? Based on the logic, the decision should be the same as in this bug.

The last logical thing is that you shouldn't spam highlight of any kind to a user who doesn't use Tab
key (i.e. mostly uses mouse). Even if he accidentally pressed Tab key once. But you always show it.
This one is a work for Core developers actually; I only mentioned it, because you played with that highlight too much. People that DO NOT use accessibility stuff DO NOT need that highlight, ever.
(GoogleChrome handles the last one BTW)

Comment 12

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/1663fc366770

Comment 13

[Brian Grinstead [:bgrins]]

(In reply to arni2033 from comment #11)
arni, please be respectful of differing viewpoints and experiences.  We need to make sure that working on this project is a positive experience for people.  Calling someone else's work "the worst" or implying that they are illogical is demotivating and mean.  Also, it detracts from your suggestions and solutions, which are usually quite good.

I know you're a committed contributor and I appreciate all the work you do, but please don't make comments personal.

Comment 14

[Oriol Brufau [:Oriol]]

Maybe arni2033 was a bit rantish, but I agree with the raised points:

 - The new style is incoherent with other inputs, e.g. the filter one just a little above,
   which is highlighted instead
 - It looks old
 - Dotted outlines are not drawn in text inputs
 - Dotted outlines are not drawn when the input is accessed using the mouse

In fact, the first time I saw the dotted outline, I thought it was a regression, not a feature.