New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 635971 link

Starred by 1 user

Issue metadata

Status: ExternalDependency
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug



Sign in to add a comment

<button> - ambiguous behavior for matches(':active') inside of event listeners

Project Member Reported by traviskaufman@google.com, Aug 9 2016

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.82 Safari/537.36

Steps to reproduce the problem:
1. Create a button element (let's call it "btn")
2. Create a function "isActive" with the body - console.debug(btn.matches(':active'));
3. Add isActive as an event listener for 'mousedown', 'mouseup', 'keydown', and 'keyup' on the button
4. Attach the button to the DOM (or, if already part of the DOM, do nothing)
5. Using a mouse or trackpad, press down on the button, and then release
6. Notice how "true" was logged when the mouse was pressed down, followed by "false"
7. Activate the button by pressing the spacebar down, and then quickly releasing
8. Observe the logged output

What is the expected behavior?
Similar to the mousedown event, "true" should be logged on keydown, and "false" should be logged on keyup.

What went wrong?
The opposite of what's expected happens. When the spacebar is pressed, "false" is logged. When it is released, "true" is logged. However if the spacebar is held down, "true" begins to be logged.

Did this work before? N/A 

Chrome version: 52.0.2743.82  Channel: stable
OS Version: OS X 10.11.6
Flash Version: Shockwave Flash 22.0 r0

Reproducible test case at https://jsfiddle.net/2vmtochy/

It seems like this is a race condition between when the keydown event is fire and when the button becomes active. A workaround seems to be  wrapping the matches() call in a requestAnimationFrame, which I've included in the fiddle.

I would imagine that this behavior should be deterministic. According to the specification, "The element is being activated if it is in a formal activation state and it is not disabled...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." (https://html.spec.whatwg.org/multipage/scripting.html#selector-active)
 
Components: -UI Blink>JavaScript Blink>Focus Blink
Labels: -OS-Mac Hotlist-Google OS-All
Status: Untriaged (was: Unconfirmed)
Confirmed on 54.0.2816.0 (Official Build) dev (64-bit) under Linux.
Components: -Blink>Focus -Blink>JavaScript -Blink Blink>Input
Cc: nzolghadr@chromium.org
Labels: Hotlist-Input-Dev
Owner: chongz@chromium.org
Status: Assigned (was: Untriaged)
I can reproduce that on Mac with Canary 54.0.2826.0.
Chong, is this something you can take a look?

Comment 4 by chongz@chromium.org, Aug 16 2016

Cc: dtapu...@chromium.org
Status: Started (was: Assigned)
The problem is whether the browser handles ':active' state before (or during) default action.
@dtapuska do we have any spec about the timings?

Tested on Safari, FF and Edge, the behavior seems unpredictable:
For mouse click:
  * Chrome, Safari and Edge handles ':active' before default 'mousedown' action.
  * Firefox handles during default 'mousedown'.

For space key:
  * Edge handles before default.
  * Chrome handles during default.
  * Firefox doesn't set ':active'.
  * Failed to test on Safari, was not able to focus button using Tab.

I'm not sure if it's worth changing the behavior to match Edge? (since everyone is different)

Test Case: https://output.jsbin.com/veyoditiyo/quiet
(`btn.matches(':active')` doesn't work outside jsfiddle, no idea why)
@chongz FWIW I filed an issue with FF regarding their click behavior - https://bugzilla.mozilla.org/show_bug.cgi?id=1293741
Status: ExternalDependency (was: Started)
Waiting for FF's input.

Comment 7 by chongz@chromium.org, Jan 11 2018

Cc: chongz@chromium.org
Owner: dtapu...@chromium.org
Still waiting for FF's input. Re-assigning to dtapuska@.

Sign in to add a comment