1220143 - .focus() in onkeydown handler causes a click event on a link when pressing the Enter key

Status: UNCONFIRMED

(Core :: DOM: Events, defect, P3)

Description

[Andy Harrison]

Attachment: focusClick.htm

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:41.0) Gecko/20100101 Firefox/41.0
Build ID: 20151014143721

Steps to reproduce:

1. Add a keydown event listener to a focusable element (I tried it with both a text input and a <span> with tabindex="0"). In the event handler, focus on an <a> element using .focus()
2. Focus on the focusable element
3. Press the Enter key


Actual results:

1. A focus event was triggered on the link
2. A click event was triggered on the link


Expected results:

1. A focus event was triggered on the link

Comment 1

[Alice0775 White]

Seems dup of Bug 931652 and bug 886268

Comment 2

[Andy Harrison]

Bug 931652 seems to be the reverse: click causing an unexpected focus.

Comment 3

[thomas.jaggi]

Another example: http://jsbin.com/bibiwo/edit?html,js,output

Comment 4

[thomas.jaggi]

(In reply to thomas.jaggi from comment #3)
> Another example: http://jsbin.com/bibiwo/edit?html,js,output

It shows a real-world example where a basic modal implementation doesn't work properly since moving the focus to the close button when opening it will immediately close it again.

Comment 5

[thomas.jaggi]

Possible workaround temporarily disabling click events when moving focus on space: http://jsbin.com/teciva/edit?html,js,output

Comment 6

[thomas.jaggi]

A way simpler solution for my specific problem seems to be using `keyup` instead of `keydown` for the space key: http://jsbin.com/tijuqes/edit?html,js,output
This would be more consistent with how the browser treats space on native buttons anyway.

Comment 7

[Pascal Duez [:pldz]]

Same issue here but with the "Space" key, "Enter" is fine.
Quite problematic when implementing a11y keyboard navigation for components like menu buttons.
https://www.w3.org/TR/wai-aria-practices-1.1/examples/menu-button/menu-button-actions.html

User Agent: "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0"

Comment 8

[Mu-An Chiou (muan)]

Another example with "Space" key causing this problem on GitHub, where we implement the ARIA menu pattern via <details-menu> (similar to https://bugzilla.mozilla.org/show_bug.cgi?id=1220143#c7)

Steps:

1. Go to https://github.github.io/details-menu-element/examples/,
2. Tab to the first menu button, press "Enter" to open it,
3. Tab to the first menu item, press "Space" to select it,
4. Observe that menu is closed but immediately opened again.

This can be further verified by registering a click event listener on <summary>. It does not happen on Chrome nor Safari.

On github.com, you can see this happening in the dropdown menus on the right side header for both the + icon menu, and the personal menu.

Here's a GIF showing this behavior on GitHub menu: https://cl.ly/114b7b4ec86b/Screen%20Recording%202020-03-20%20at%2015.48.gif

UA: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:74.0) Gecko/20100101 Firefox/74.0

Comment 9

[Mu-An Chiou (muan)]

Here's a reduced test case: https://html-is.glitch.me/firefox-space-focus.html

Comment 10

[Mu-An Chiou (muan)]

I've submitted a WPT for the space trigger issue: https://github.com/web-platform-tests/wpt/pull/22424

Comment 11

[Tom S. (please needinfo tschuster)]

We create the click event based on keypress with enter and keyup with space here: https://searchfox.org/mozilla-central/rev/06985b12a4abe393c02c6bf14d86bf3d25c33337/dom/html/HTMLButtonElement.cpp#235-244.

Somehow we need to suppress this click event if the initial keydown event was on a different element. We actually have PresShell::EventHandler::sLastKeyDownEventTargetElement; (source) already so maybe we could do this? Masayuki seems to have added this, so needinfo-ing them.

Comment 12

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

I don't understand the logic for now. keypress event should be fired on any browsers for Space and Enter key press. So, keypress event should be tested in the WPT. Do you think which one of the following is expected behavior?

option: 1

1. keypress event should be fired on previously focused element.
2. click event should be fired as the default action if the previously focused element's normal behavior is so.

option: 2

1. keypress event should be fired on newly focused element.
2. But it's default action shouldn't be performed by the keypress event.

option: 3

1. keypress event should be fired on previously focused element.
2. But it's default action shouldn't be preformed due to blurred.

If the last one, I have another question. If the keypress event listener takes back focus to the event target (previously focused element), the element should perform default action?

Anyway, I'm feeling odd to the WPT's expectation because nobody prevents its default.

Comment 13

[Mu-An Chiou (muan)]

keypress event should be fired on any browsers for Space and Enter key press. So, keypress event should be tested in the WPT.

That wouldn't give us the test failure though. Both Chrome and Safari have keypress fired on the newly focused button, but neither triggered click, which means option 2. As far as I can see, the previously focused element wasn't clicked in any browser despite nobody prevented default.

Comment 14

[Mu-An Chiou (muan)]

According to wpt.fyi, this has been fixed in https://wpt.fyi/results/uievents/order-of-events/focus-events/focus-management-expectations.html?label=master&label=stable&product=firefox-91.0&aligned&q=focus%20events! :tada: