New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 16 users

Issue metadata

Status: Assigned
Last visit 18 days ago
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug

Sign in to add a comment

Issue 271023: Outline should not appear on elements focused by mouse

Reported by, Aug 9 2013

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1591.0 Safari/537.36

Example URL:

Steps to reproduce the problem:
1. Disable the "Pressing Tab on a web page highlights links, as well as form fields" option
2. Use the keyboard to tab through items on a web page / mouse down on a button (but do not mouse up)

What is the expected behavior?
There should be no outline on the focused element.

What went wrong?
There is an outline, with or without the setting enabled. It also appears when you click on an element too, whereas before I believe it only appeared when you used the keyboard to tab onto the element.

Does it occur on multiple sites: Yes

Is it a problem with a plugin? No 

Did this work before? Yes 

Does this work in other browsers? Yes 

Chrome version: 30.0.1591.0  Channel: canary
OS Version: OS X 10.9.0
Flash Version: Shockwave Flash 11.8 r800
Screen Shot 2013-08-09 at 22.42.56.png
13.4 KB View Download

Comment 1 by, Aug 10 2013

Labels: Cr-Blink

Comment 2 by, Aug 11 2013

Labels: -Cr-Content Cr-Blink-Forms
Status: WontFix
This is an expected behavior since Chrome 30.  Clicking a button focuses on the button, and the button has :focus style.
Please contact to the web page author if you think this is wrong.

Comment 3 by, Oct 4 2013

Umm, this is far too obtrusive. The outline on every button seriously affects the look of the webpage — even here, on Google Code. Disabling the outline, however, also affects <tab>ing, where the outline is the only indicator of focus.

Seems like a related bug:

Focus ring appears on mouse interactions (as opposed to only when tabbing through items):

Comment 4 by, Dec 16 2013

Out of interest, why is this the behaviour for buttons but not links?

Comment 5 by, Dec 16 2013

Furthermore, this only happens on buttons when the button’s CSS background is set to `none:

Comment 6 by, Feb 1 2014

Can this be re-opened? I've got a strong feeling this is causing serious accessibility degradation on the web and the longer it remains the larger the damage.

Given that styling buttons is such a widespread practice and a blurry outline on mere clicking will likely cause developers to disable outlines entirely, we'll be left with forms that show no indication that you've tabbed to buttons. At best. At worst we'll be without all focus outlines.

Comment 7 by, May 11 2015

Status: Available
I think we should revisit this.

I agree with comment #6 - people are removing the focus style from elements to avoid this issue, which hurts accessibility overall. is just one example of advice to remove the focus ring to avoid this issue.

Comment 8 by, May 11 2015

Labels: Cr-UI-Accessibility

Comment 9 by, Jul 27 2015

Labels: -Cr-Blink

Comment 10 by, Aug 25 2015

In agreement with #3, #6, and #7. I'm getting requests from the UX team to remove the outline on click... when in fact that's out of my hands. Setting the focus state to outline: 0 is not a viable alternative since it hurts accessibility.

Any chance this can get looked at again?

Comment 11 by, Aug 25 2015

Also, in response to #5, it looks like the focus ring is showing up on click when the background property has been set to any value, not just "none".

Leaving background untouched, it correctly does not show the focus ring on click.

Comment 12 by, Aug 26 2015

Labels: -OS-Mac Cr-Blink-Focus
Owner: ----
At this moment we can do nothing for Chromium/Blink.  We need to focus on an element when it is clicked, and it should be matched to :focus.

Web authors can implement the desired behavior by small JavaScript code.  Example:

The best solution would be the CSS standard introduces a pseudo selector like :focused-by-pointer or :focused-by-keybaord.

Comment 13 by, Aug 26 2015

Well, how does Firefox handle this internally? They _don't_ apply `:focus` on a mouse click at least. Only when you tab to buttons.

Comment 14 by, Aug 27 2015

Apparently this has already been fixed. See #5 in

Comment 15 by, Oct 1 2015

Status: Fixed
Ok, let's close this as it's already fixed.

Adding rob@ in cc so he could verify.

Comment 16 by, Oct 1 2015

I cannot verify the bug because I don't see a clear bug description here.

Comment 17 by, Oct 2 2015

Status: Available
Summary: Outline should not appear on elements focused by mouse (was: Outline appears on focused element all the time)
The bug is, for example,

1. open data:text/html;charset=utf-8,<button type=button style="background:gray">Button</button>
2. Click on the button by a mouse (not TAB focus navigation)

Expected: The button has no focus ring
Actual: The button has focus ring

So, we don't fix this yet.

Comment 18 by, Oct 2 2015

I've tested the following in several browsers (, by clicking on the button and moving the mouse away (to avoid :hover effects):
1: <button>Button default</button>
2: <button style="background:gray">Button gray</button>
3: <button class=outline-focus>Button :focus outline</button>
   <style>.outline-focus:focus { outline: 1px solid red; }</style>

In all browsers, button 2 looks different from 1 and 3 (button 1 and 3 has a "native" style, while 2 looks like an ugly styled button with a custom background).

Has focus effect, for each of the buttons?
- Safari 5.1 (Windows 7-10) : N N N (note1)
- Safari 9 (OS X 10.11)     : N N N (note1)

- IE Edge (Windows 10)      : N N Y
- IE 11 (Windows 7, 8.1, 10): N Y Y (note2, note3)

Firefox follows the platform conventions.
- Firefox 41 (Linux)        : Y Y Y (note2, note4)
- Firefox 41 (Windows 10)   : Y Y Y (note2, note4)
- Firefox 41 (Windows 7-8.1): Y N Y (note3)
- Firefox 41 (OS X 10.11)   : N N N

Chrome has a uniform styling across platforms.
- Chrome 47 (Linux)         : N Y Y
- Chrome 47 (Windows 10)    : N Y Y
- Chrome 47 (OS X 10.11)    : N Y Y

Opera Presto is no longer used, but I'm showing it because it's a different rendering engine.
- Opera 12.16 (Windows 8.1) : Y Y Y (note2)
- Opera 12.15 (OS X 10.11)  : Y Y Y (note2)

* note1: Does not focus the buttons, let alone activate :focus upon click, even after enabling "Press tab to highlight each item on a webpage".
* note2: button 2's visual focus differs from button 1's focus effect (shown by clicking on button 1 or tabbing to it if clicking does not activate a focus effect).
* note3: IE's visual focus on button 2 is subtle: the inner border becomes slightly thicker.
* note4: Firefox's visual focus is subtle: a dotted box inside the button.

There is no consistency in focus effects upon click among browsers, but the browsers made by OS vendors (IE Edge, OS X) seem to prefer no focus effect after clicking a button. Firefox attempts to match platform conventions (
Therefore I think that we should indeed change Chrome's behavior, and not show the focus ring after clicking the button (probably with logic similar to my a[href]:focus changes in  bug 388666 ).

<button>s are not the only form element, are there any other elements that need such visual changes?

Comment 19 by, Oct 4 2015

Windows 10 seems pretty inconsistent. The newer Windows UWP dialogs (e.g., windows 10 settings) never show focus on mouse down. Other programs like Paint will not show focus in some cases (open file dialog accessed via the ribbon button) but will in others (open file dialog accessed via ctrl+o). The Windows 10 start menu works more like UWP/OSX and does not show focus on mouse down. Firefox/Opera may not have made the same decision if Windows 10 had been out back then.

Android also works like UWP/OSX.

How do folks feel about contacting the Edge and Firefox teams about unifying on the UWP/OSX behavior, both for {browser,platform} consistency and so users don't break accessibility due to this?

Comment 20 by, Oct 5 2015

Labels: Cr-Blink-Paint
+1, let's improve compat on this.

Comment 21 by, Oct 7 2015

Some discussions in WICG: Detecting users don’t require visible focus rings Exposing a user's input modality

Comment 22 by, Oct 7 2015

Labels: -Cr-Blink-Paint
Removing Cr-Blink-Paint since this is not really a paint bug.

Comment 23 by, Jun 16 2016

Status: ExternalDependency (was: Available)
Tab proposed :focus-ring.

We can implement it so that it matches only when an element was focused by keyboard.
We'd like to implement it when it is added to the CSS selectors specification.

Comment 24 by, Mar 26 2017

Labels: Needs-BlinkIntent
Status: Available (was: ExternalDependency)
:focus-ring is on the draft.  We should send intent-to-implement (and ship).

Comment 25 by, Mar 28 2017

Labels: NewComponent-Accessibility-Blink NewComponent-Accessibility

Comment 26 by, Apr 21 2017

Components: Blink>Accessibility

Comment 27 by, Apr 21 2017

Components: -UI>Accessibility
Labels: -newcomponent-accessibility-blink -newcomponent-accessibility

Comment 28 by, Jul 27 2017

Labels: triage-dominic

Comment 29 by, Jul 31 2017

Labels: -Via-Wizard -triage-dominic

Comment 30 by, Sep 29 2017

Components: Blink>HTML>Focus

Comment 31 by, Sep 29 2017

Components: -Blink>Focus

Comment 32 by, Oct 1

Project Member
Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit - Your friendly Sheriffbot

Comment 33 by, Oct 1

:focus-visible is in the spec, and implemented in Chrome now. @aboxhall, it seems like we can close this?

Comment 34 by, Nov 9

Status: Assigned (was: Untriaged)

Sign in to add a comment