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.

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:
https://code.google.com/p/chromium/issues/detail?id=25518

Focus ring appears on mouse interactions (as opposed to only when tabbing through items):
https://bugzilla.mozilla.org/show_bug.cgi?id=418521

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

Furthermore, this only happens on buttons when the button’s CSS background is set to `none: http://jsbin.com/oJUNAkaT/2/edit

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.

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. http://stackoverflow.com/questions/19053181/how-to-remove-focus-around-buttons-on-click is just one example of advice to remove the focus ring to avoid this issue.

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?

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.

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: https://chromium.googlesource.com/chromium/src/+/master/ui/webui/resources/js/cr/ui/focus_outline_manager.js

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

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

Apparently this has already been fixed. See #5 in https://code.google.com/p/chromium/issues/detail?id=521305#c5.

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

Adding rob@ in cc so he could verify.

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

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.

I've tested the following in several browsers (http://jsfiddle.net/t9g1403n/1/show), 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.


CONCLUSION
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 (https://developer.mozilla.org/en-US/docs/Web/CSS/:-moz-focusring).
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?

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?

+1, let's improve compat on this.

Some discussions in WICG:

http://discourse.wicg.io/t/detecting-users-dont-require-visible-focus-rings/804 Detecting users don’t require visible focus rings

http://discourse.wicg.io/t/exposing-a-users-input-modality/1067 Exposing a user's input modality

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

Tab proposed :focus-ring.
https://lists.w3.org/Archives/Public/www-style/2015Sep/0226.html

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.

:focus-ring is on the draft.  We should send intent-to-implement (and ship).

https://drafts.csswg.org/selectors/#the-focusring-pseudo

https://github.com/wicg/focus-ring

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 https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

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