Open Bug 68851 Opened 22 years ago Updated 1 year ago

HTML buttons should go :active on keydown (spacebar)

Categories

(Core :: Layout: Form Controls, defect)

x86
All
defect
Not set
normal

Tracking

()

Future

People

(Reporter: bugzilla, Unassigned)

References

Details

(Keywords: access)

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.
accepting and futuring
Status: NEW → ASSIGNED
Target Milestone: --- → Future
QA Contact Update
QA Contact: bsharma → vladimire
*** Bug 142269 has been marked as a duplicate of this bug. ***
OS: Windows 2000 → All
*** Bug 186543 has been marked as a duplicate of this bug. ***
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.)
Assignee: rods → form
Status: ASSIGNED → NEW
Keywords: qawanted
QA Contact: vladimire → ian
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.
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.
Creating a test case
Creating a test case
Duplicate of this bug: 417097
Assignee: layout.form-controls → nobody
QA Contact: ian → layout.form-controls
Is any part of this bug still valid?
Keywords: qawanted
Duplicate of this bug: 908668
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.
(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)
Duplicate of this bug: 1313999
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.
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.
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.
Summary: HTML buttons should go :hover:active on keydown (spacebar) → HTML buttons should go :active on keydown (spacebar)
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.
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.
> 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...
Duplicate of this bug: 1362316
Keywords: access

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

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.

You need to log in before you can comment on or make changes to this bug.