HTML buttons should go :active on keydown (spacebar)

NEW
Unassigned

Status

()

Core
Layout: Form Controls
17 years ago
6 months ago

People

(Reporter: Blake Ross, Unassigned)

Tracking

Trunk
Future
x86
All
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

17 years ago
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

17 years ago
accepting and futuring
Status: NEW → ASSIGNED
Target Milestone: --- → Future

Comment 2

17 years ago
QA Contact Update
QA Contact: bsharma → vladimire

Comment 3

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

Updated

16 years ago
OS: Windows 2000 → All

Comment 4

15 years ago
*** 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

Comment 6

14 years ago
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

14 years ago
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

13 years ago
Creating a test case

Comment 9

13 years ago
Creating a test case

Updated

10 years ago
Duplicate of this bug: 417097
Assignee: layout.form-controls → nobody
QA Contact: ian → layout.form-controls

Comment 11

4 years ago
Is any part of this bug still valid?
Keywords: qawanted

Updated

4 years ago
Duplicate of this bug: 908668

Comment 13

4 years ago
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

4 years ago
(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)

Updated

a year ago
Duplicate of this bug: 1313999

Comment 16

6 months ago
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

6 months ago
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.

Comment 20

6 months ago
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...
You need to log in before you can comment on or make changes to this bug.