REPRO * 1. Load attached test case. 2. Tab so that focus is on one of the buttons. 3. Perform a mouse click on the same button. (Notice focus ring disappears.) 4. Press Tab again. (focus has been lost and resets to the beginning of the document) Note: It's probably okay to "hide" the focus pseudo-state when switching to a mouse, but Tabbing should cause focus to come back to the same element rather than losing document.activeElement entirely.
Created attachment 194349 [details] test case demonstrating bug
<rdar://problem/13477257>
See expected behavior in Firefox 19 for Mac.
<rdar://problem/13477269>
See also: bug 22261.
Any updates on this? I see that there's not been any changes since the bug was reported 5 years ago. This issue makes building custom widget with focus management very tricky.
Relating to the newer :focus-visible tracker in bug 225148
Very related bug, see bug #229895.
Just talked about this at TPAC with ntim and jcraig I just want to add to the repro steps: REPRO * 1. Load attached test case. 2. Tab so that focus is on one of the buttons. 3. Perform a mouse click on the same button. (Notice focus ring disappears.) 4. Press Tab again. (focus has been lost and resets to the beginning of the document) As of 16.6, step 4 is no longer the case. the next focus point does land on the button. However if you do `setInterval(() => console.log(document.activeElement), 1000)` to observe the current focused element, you would see that after step 3, the activeElement goes back to body. nTim mentioned that there has been a recent fix to account for how button[tabindex=0] should be click-focusable like div[tabindex=0]. https://github.com/WebKit/WebKit/pull/12743 Now that :focus-visible is implemented, I wonder if WebKit would mind reconsidering this special treatment (https://github.com/WebKit/WebKit/blob/b38121da42a0483fdb1bc13782f1c7a8059de100/Source/WebCore/html/HTMLFormControlElement.cpp#L255C13-L255C13) to buttons?