Hide auto-style link outline when focused with mouse (was: hide dotted outline on focused (tapped) links on Firefox for Android)
Categories
(Core :: DOM: UI Events & Focus Handling, defect, P2)
Tracking
()
People
(Reporter: abovens, Assigned: emilio)
References
Details
(Whiteboard: [geckoview:fenix:p3][layout:backlog:2019q2])
Attachments
(2 files)
The dotted outline on tapped links feels out of place on mobile. The outline is a repurposed "focus" outline, but it's only visible for a brief moment, and doesn't add much value.
Steps to reproduce:
- Perform a Google search
- Tap on one of the search results
The tapped search result will have an outline.
|
||
Updated•5 years ago
|
|
||
Comment 1•5 years ago
|
||
This bug also affects GV in Fenix.
|
|
||
Updated•5 years ago
|
|
||
Comment 2•5 years ago
|
||
Emilio: Is this just a UA stylesheet tweak for mobile on :focus, or is it more involved than that?
|
|
||
Updated•5 years ago
|
|
Assignee | |
Comment 3•5 years ago
|
||
We have prefs to control the default focus outline already that could be tweaked (browser.display.focus_ring_*).
Though note that the ugly outline described in https://github.com/mozilla-mobile/fenix/issues/2184 in Google search should be fixed on trunk via bug 1548809.
|
Reporter | |
Comment 4•5 years ago
|
||
Note that I'd still like focus outlines to work (e.g. for when a physical keyboard is used on Android tablets). However, the outline shouldn't be shown when just tapping a link.
|
|
Assignee | |
Comment 5•5 years ago
|
||
So CSS basically knows whether something is focused or not. Let me check what WebKit or Blink do...
Looking at Blink, it looks like they only show the focus outlines for anchors if they weren't focused with the mouse (which also includes taps of course):
And the outline-style is auto (so if you manually specify other outline-style it'd show up):
This behavior also applies to desktop. I think associating this with outline-style: auto makes sense, and implementing something like this shouldn't be too terrible.
WDYT Andreas? Do you think something like that a reasonable behavior? Or do you also want non-auto outlines to be suppressed and such?
|
|
Reporter | |
Comment 6•5 years ago
|
||
Sorry for the late answer. That seems like a good path forward indeed.
|
|
Assignee | |
Updated•5 years ago
|
|
|
Assignee | |
Comment 7•5 years ago
|
||
Hmm, looking a bit more into it, this should (kind-of) already be happening. This is what :-moz-focuring is supposed to do... But it doesn't.
I'm seeing some very bizarre things. For example, if I open this from a file (let's call it t.html), it does show a focus outline, since we put a :-moz-focusring pseudo-class on it.
<!doctype html><a href="foo">Link</a>
However if I load it from a data URI: data:text/html,<!doctype html><a href="foo">Link</a>, then it works as I'd expect reading the code...
So there's something somewhat weird here.
|
|
Assignee | |
Updated•5 years ago
|
|
|
Assignee | |
Updated•5 years ago
|
|
|
Assignee | |
Comment 8•5 years ago
|
||
It's only moved around, but not actually used anywhere.
I have no idea what this was supposed to control in the past but it doesn't seem
useful to keep it around.
|
|
Assignee | |
Comment 9•5 years ago
|
||
This pref toggled gives me the desired behavior on Linux, and it should be
trivial to revert to the previous behavior if needed.
Depends on D33393
|
||
Comment 10•5 years ago
|
||
I have no idea what this was supposed to control in the past but it doesn't seem
useful to keep it around.
It's there in case someone wants to implement bug 25894.
|
|
Assignee | |
Comment 11•5 years ago
|
||
(In reply to Neil Deakin from comment #10)
I have no idea what this was supposed to control in the past but it doesn't seem
useful to keep it around.It's there in case someone wants to implement bug 25894.
Maybe the code should be re-introduced then? It's mostly plumbing.
|
|
Assignee | |
Comment 12•5 years ago
|
||
But I'm happy to keep it around, just let me know.
|
||
Updated•5 years ago
|
|
||
Comment 13•5 years ago
|
||
Pushed by ealvarez@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/8d2dcfb9a9b6 Remove dead code for threading accelerator state. r=NeilDeakin https://hg.mozilla.org/integration/autoland/rev/62c41bc07a49 Make whether to show focus-rings for all content by default a pref, and disable it on Android. r=NeilDeakin
|
|
||
Comment 14•5 years ago
|
||
68=wontfix because it's a little late in the 68 Beta cycle to uplift a UX style fix.
|
||
Comment 15•5 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/8d2dcfb9a9b6
https://hg.mozilla.org/mozilla-central/rev/62c41bc07a49
|
||
Comment 16•5 years ago
|
||
QA found that the play button on speedtest.telstra.com still shows an outline while tapping it, and I can reproduce.
See https://github.com/mozilla-mobile/fenix/issues/2184#issuecomment-533530018
|
|
Assignee | |
Comment 17•5 years ago
|
||
Please file a different bug to investigate that, rather than reopening fixed bugs.
I've checked and at least on google results and normal links there's no outline anymore, so chances are this is a problem specific to that website.
|
|
Assignee | |
Comment 18•5 years ago
|
||
In particular, that page doesn't use a link, it uses a <button>, so what you're seeing is not the outline but the ::-moz-focus-inner border. Which websites can override, but probably won't.
So we need to come up with a solution for that I guess, but that's a totally different issue (see also bug 1580935).
|
|
||
Comment 19•5 years ago
|
||
(In reply to Emilio Cobos Álvarez (:emilio) from comment #18)
In particular, that page doesn't use a link, it uses a
<button>, so what you're seeing is not the outline but the::-moz-focus-innerborder. Which websites can override, but probably won't.So we need to come up with a solution for that I guess, but that's a totally different issue (see also bug 1580935).
I filed bug 1583381 for the <button> outline issue. Chrome doesn't show a dotted button outline, but it does flash a blue highlight box for the same button.
Description
•