68851 - HTML buttons should go :active on keydown (spacebar)

Status: NEW

(Core :: Layout: Form Controls, defect)

Description

[Blake Ross]

Build ID: trunk (tip)

HTML buttons should go to the :hover:active state as you press spacebar and 
return to normal when you release it.  Look in nsButtonBoxFrame.cpp to see how 
we do this for chrome.

Comment 1

[rods (gone)]

accepting and futuring

Comment 2

[Vladimir Ermakov]

QA Contact Update

Comment 3

[R.K.Aa.]

*** Bug 142269 has been marked as a duplicate of this bug. ***

Comment 4

[Sander]

*** Bug 186543 has been marked as a duplicate of this bug. ***

Comment 5

[Boris Zbarsky [:bzbarsky]]

Wouldn't this break the actual hover/active?  For example, if my mouse is
hovering something and I hit spacebar on a button, should the thing that was
being hovered go out of hover?  And when I release the spacebar, should the
thing that was being hovered become hovered again? (This part I think
nsButtonBoxFrame screws up.)

Comment 6

[XFox]

If you click a link that has a:active{background-color:red} without releasing
the mouse button, try to drag it, then release it,the effects of the red
background will become permanent until the link is clicked again. This is
reproducable in both Mozilla 1.6 and Firefox 0.8. Also, I'm not sure which is
standard, but the expected result of the :active pseudo-element varies between
IE and Mozilla. Mozilla treats a link as a puch button (no longer active when
the mouse button is released) but IE will keep it active until focus is removed
from it. I'm in favor of Mozilla's implementation though.

Comment 7

[Jerry Baker]

This should break :hover since clicking the mouse on the same element would
break :hover. In both cases we are still "hovering" so to speak.

Comment 8

[Steve Smith]

Creating a test case

Comment 9

[Steve Smith]

Creating a test case

Comment 11

[Ioana (away)]

Is any part of this bug still valid?

Comment 13

[tzi]

I created a simple test case for this bug: http://jsfiddle.net/tzilliox/x9zqt/
An action is needed, because there is a lack of accessibility when using asynchronous forms with a keyboard.

Comment 14

[Ioana (away)]

(In reply to tzi from comment #13)
> I created a simple test case for this bug:
> http://jsfiddle.net/tzilliox/x9zqt/
> An action is needed, because there is a lack of accessibility when using
> asynchronous forms with a keyboard.

Thanks for the testcase.

This bug is definitely still reproducing:
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0 (20130826190748)

Comment 16

[Roman Komarov]

I have another two testcases:

1. http://dabblet.com/gist/79a424d82f4a5b93b0241e4bc81ad80d — really simple, works now everywhere else: in Chrome, Safari, Edge.

2. More complex, showing the states-through-transition method, which works, again, everywhere except for the keyboard activation in Fx — https://codepen.io/kizu/pen/Emqmqm

As @tzi said, that's a critical issue accessibility-wise, as if someone would implement the second method for showing/hiding functionality, then Firefox keyboard users couldn't access it.

Comment 17

[Roman Komarov]

And just in case: here is WHATWG living standard that Firefox violates with this bug, see https://html.spec.whatwg.org/multipage/scripting.html#selector-active

> For example, if the user is using a keyboard to push a button element by pressing the space bar, the element would match this pseudo-class in between the time that the element received the keydown event and the time the element received the keyup event.

Comment 18

[Boris Zbarsky [:bzbarsky]]

OK.  Matching :active makes sense here.  Matching :hover does not, right?

Let's retitle this bug to make that clear; I think the :active bit is what has prevented this from being fixed, because it was nonsensical.

Comment 19

[Boris Zbarsky [:bzbarsky]]

So at least Chrome and Safari have pretty weird behavior: they actually treats either space or enter as triggering the button, but only space as marking it :active?  That seems pretty weird.

In Edge I can't tell what's going on because at least on browserstack I don't see it marking the button as :active on space.

I filed https://github.com/whatwg/html/issues/2725 to get the spec clarified a bit here.

Comment 20

[Roman Komarov]

Just tested it at Browserstack again (Win10, Edge 15), space does trigger the :active state for me, both long pressing and very short still registers (the best place to test short presses would be my second test: https://codepen.io/kizu/pen/Emqmqm)

> I think the :active bit is what has prevented this from being fixed, because it was nonsensical.

Did you made a type and meant :hover there? If so, then yes, hover shouldn't be triggered on pressing space there.

In regards to enter — I think it should be space, as it is the thing that is supported everywhere I guess, but that's a separate issue from this one I guess.

Comment 21

[Boris Zbarsky [:bzbarsky]]

> Did you made a type and meant :hover there? 

Yes.

> In regards to enter — I think it should be space, as it is the thing that is supported everywhere I guess

All browsers will trigger activation behavior on buttons when enter is pressed, as far as I can tell.  It's just that they don't put the button in the :active state for some reason.

I still can't get Edge (same browserstack configuration as yours) to do anything wrt :active applying, on your second test.  I focused the "Show me the thing!" button and hit space bar three times just now, no results.  Maybe it depends on which OS or browser I'm using browserstack on or something...

Comment 24

[fiona.greenwood.sheridan]

Please fix this bug! this is an accessibility issue, as it means that people navigating via keyboard cannot get visual feedback on button use!

Comment 25

[Edwin Martin]

After 21 years, this bug is still valid.

People who use the keyboard to navigate, don't get visual feedback when activating a button. This does work in all other modern browsers. Please fix this.

Comment 26

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 7 duplicates.
:emilio, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 27

[Emilio Cobos Álvarez (:emilio)]

I took a look at this in bug 1481400. The behavior of other browsers when you preventDefault the event or what not is very whacky.

Comment 28

[Emilio Cobos Álvarez (:emilio)]

What's this about? If you request information without a question or so it's hard to know what to answer :)

Comment 29

[Michal Čaplygin [:myf]]

Attachment: 68851-testcase-01.html

After those years this issue maybe deserves some test case being directly attached. Test results from my machine:

Firefox 107.0b9

Outcome label	Active state matched	Focus state matched	Counter increased
Pressed Space Bar	No *	Yes	No
After pressed Space Bar	No	Yes	Yes
Pressed Enter	No **	Yes	Yes, repeatedly
After pressed Enter	No	Yes	(No)

Google Chrome 106.0.5249.103

Outcome label	Active state matched	Focus state matched	Counter increased
Pressed Space Bar	Yes	Yes	No
After pressed Space Bar	No	Yes	Yes
Pressed Enter	No **	Yes	Yes, repeatedly
After pressed Enter	No	Yes	(No)

* That's what this issue is about.
** Interesting question whether this is right, but at least both implementations match.

There are many discrepancies in those implementations not covered in test case, for example Chrome gives active state to button while pressed by middle and right mouse buttons (but does not produce activation event) and when activated through corresponding <code>label</code> (in the first step's text), but only on the first click.

If anyone wanted to test other browser and share results, template:

## Browser

| Outcome label | Active state matched | Focus state matched | Counter increased |
| - | - | - | - |
| Pressed Space Bar | . | . | . |
| After pressed Space Bar | . | . | . |
| Pressed Enter | . | . | . |
| After pressed Enter | . | . | . |

---

I think that bug 1481400 is in fact not related to this one at all; I remember YouTube used to have two event listeners that were fired simultaneously when the play button was "keyboard-clicked" and really forgot to stop event propagation from the "keyboard space bar 'click'" to body space bar keypress listener.
This particular issue is about interactive state interpretation in CSS, not preventDefaulting in JavaScript. (But as always, I might be wrong.)

Comment 30

[Emilio Cobos Álvarez (:emilio)]

(In reply to Michal Čaplygin [:myf] from comment #29)

This particular issue is about interactive state interpretation in CSS, not preventDefaulting in JavaScript. (But as always, I might be wrong.)

For the record, they are somewhat related because at least in that other bug, Blink and WebKit used :active to determine whether they should fire the default action.