Bug 281430 – click events invoked with keyboard have fictitious screenX, screenY, clientX, clientY values

• Component: UI Events
• Status: NEW

[Josh Tumath]

Problem:

Click events use the MouseEvent class. However, click events can be invoked with keyboards, too.

There is an interoperability issue with how the screenX, screenY, clientX and clientY coordinate values are set in WebKit vs Gecko and Chromium.

- In WebKit, a keyboard invocation sets the coordinate values to be as if the target was clicked in the very centre.
- In Gecko and Chromium, a keyboard invocation sets the coordinate values to 0.

See CodePen for a demo: https://codepen.io/joshtumath/pen/bGXqqZY


Further information:

Gecko and Chromium's solution is advantageous, because it can be used to check if the click event was invoked with a keyboard or pointer. If the event was invoked with a keyboard, a function like this can be used to detect that:

  const clickEventHandler = (event) => {
    const possiblyInvokedByKeyboard = event.screenX === 0 || event.screenY === 0;
  }

In WebKit, there is no other way AFAIK to detect if a click event was invoked by a keyboard.


Expected behaviour:

I expect WebKit to have the same behaviour as Gecko and Chromium.

[Alexey Proskuryakov]

Thank you for the report. Could you please clarify why you find it beneficial to be able to detect that the event was sent from keyboard? 

To me, that seems like a downside, as it increases the risk of website malfunction for accessibility users - one would want accessibility to take normal well-tested code paths as much as possible.

[Josh Tumath]

(In reply to Alexey Proskuryakov from comment #1)
> Thank you for the report. Could you please clarify why you find it
> beneficial to be able to detect that the event was sent from keyboard? 
> 
> To me, that seems like a downside, as it increases the risk of website
> malfunction for accessibility users - one would want accessibility to take
> normal well-tested code paths as much as possible.

Ironically, I want interoperability on this to help with use cases relating to accessibility.

I work at the BBC and, on our UK website, our navigation bar menu button behaves slightly differently depending on if it is opened with a pointer or keyboard. The click event will always open the menu, but:

- when opening with a pointer, the focus moves to the menu container.
- when opening with a keyboard, there is no animation to open the menu and the focus moves to the first link in the menu.

Often when opening a menu, we don't want a slightly different behaviour around focus and animations depending on if the user 'clicks' with a pointer or keyboard.

The 'click' event is great when creating user experiences for keyboard users because it is device independent. On keyboards, it is only invoked by Space or Enter key presses. If we were to use the keydown event, we would have to check whether only the the Space or Enter keys were pressed.

[Alexey Proskuryakov]

Thank you for these details!

[Radar WebKit Bug Importer]

<rdar://problem/138044473>

[Abrar Rahman Protyasha]

This may be silly, but I can't figure out how to invoke a click with my keyboard? Any clues? (In the CodePen demo)

[Alexey Proskuryakov]

I focused the button with Option-Tab, and pressed Space. In other browsers, it remains focused after the first mouse click (please let's not talk about that detail here!)

This would certainly be an easy fix mechanically; deciding whether to match other browsers or to convince them to match WebKit could be trickier. The use case details that were posted are certainly helpful, but don't make it an obvious choice to me.

[Karl Dubost]

Some other context about the bug history 
https://www.joshtumath.uk/posts/2024-11-08-how-a-bbc-navigation-bar-component-broke-depending-on-which-external-monitor-it-was-on/

> Gecko and Chromium's solution is advantageous

But as you've demonstrated in your blog, it also allows people to write code that relies on it, and even the fixed code will have a pixel with incorrect behaviour at (0, 0). It's probably better to rely mousedown or keydown handlers for animations and unusual focus behaviour, and limit click handlers to stuff that's input agnostic.

Or if you really need a hack, UIEvent.detail seems to have good support, so perhaps you could check if this exists on the event and is set to 0.

[Josh Tumath]

(In reply to marksteward from comment #8)
> > Gecko and Chromium's solution is advantageous
> 
> But as you've demonstrated in your blog, it also allows people to write code
> that relies on it, and even the fixed code will have a pixel with incorrect
> behaviour at (0, 0). It's probably better to rely mousedown or keydown
> handlers for animations and unusual focus behaviour, and limit click
> handlers to stuff that's input agnostic.

It's certainly debatable, but regardless of my use case, this bug is about the interop issue.

As Schepp pointed out on Mastodon (https://mastodon.social/@Schepp/113465217716704956), the behaviour on Chromium and Firefox seems to be related to the Window Management API's virtual screen arrangement. So this behaviour is in a spec. https://w3c.github.io/window-management/#concept-virtual-screen-arrangement

To be clear, I'm not suggesting it's wrong for a browser to create an event with (screenX, screenY) of (0, 0).

[Brent Fulgham]

I've spoken with our standards team about this topic (thank you Anne!), who agree we are not complying with the standard:

The standard defines the behavior here:
https://html.spec.whatwg.org/multipage/interaction.html#activation

Second paragraph from that link points to https://html.spec.whatwg.org/multipage/webappapis.html#fire-a-synthetic-pointer-event

While the spec doesn't clearly state that the synthetic pointer event should be initialized to (0, 0), the intent is that you get the same as if you did new PointerEvent and then overwrote a couple fields as specified.

This could be made clearer in the spec, but indeed Webkit's behavior does not look right.

We want to make sure we comply with the spec, but do not damage the platform AX features on our platform.

[Anne van Kesteren]

I filed https://github.com/whatwg/html/issues/12117 after we had some further discussion internally.

[Josh Tumath]

When I first posted this issue, I gave my opinion that Gecko and Chromium had the desired behaviour because authors can detect if the coordinates are 0 in order to check if the event was invoked by a keyboard.

But as I said on whatwg/html#12117:

> Now that clicks are PointerEvents rather than MouseEvents, authors can use the pointerId or pointerType to detect if a non-pointing device invoked it. A keyboard sets the pointerId to -1 and pointerType to "".

As my needs are now met through those properties instead, I'm fine with any coordinate values for keyboard-invoked clicks as long as it's interoperable.

[Brent Fulgham]

Thank you, Josh. I spoke with some Accessibility folks at Apple, and the (0, 0) behavior we used to have (and Chrome and Firefox still have) has apparently led to some bad experiences for users with Assistive Technology needs (where some element interactions don't work properly).

I think we will keep this unchanged for now and work with the standards bodies to decide the right path forward.