Open Bug 68851 Opened 24 years ago Updated 2 years ago

HTML buttons should go :active on keydown (spacebar)

Categories

(Core :: Layout: Form Controls, defect)

Product:
Core
Component:
Layout: Form Controls
Platform:
x86
All
Type:
defect

Tracking

()

Milestone:
Future

People

(Reporter: bugzilla, Unassigned)

References

Details

(Keywords: access)

Attachments

(1 file)

68851-testcase-01.html
(deleted), text/html
Details
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
Assignee: layout.form-controls → nobody
QA Contact: ian → layout.form-controls
Is any part of this bug still valid?
Keywords: qawanted
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)
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...
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.

Severity: normal → S3

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.

Flags: needinfo?(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.

Flags: needinfo?(emilio)
See Also: → https://bugzilla.mozilla.org/show_bug.cgi?id=1481400
Flags: needinfo?(emilio)

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

Flags: needinfo?(emilio)
Attached file 68851-testcase-01.html (deleted) —

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.)

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

Attachment

General

Creator:
Created:
Updated:
Size: