I thought we checked FireFox and they didn't seem to send 229 for virtual keyboard events anymore.

Do we really require these events these days? Perhaps the web has moved enough that they aren't necessary. aelias@ do you have the entire history of why these events were necessary?

All of the browsers are pretty different last I checked, but it would be worth another triage.  I recall the majority of browsers send *some* keydown around composition updates although sometimes it was 0 rather than 229.

The initial history is that Windows sent them, then some but not all other OSes/browsers also sent them.  It seems potentially useful to trigger generic behaviors (e.g. visual highlighting) on any interaction with a textbox, without needing to enumerate every possible composition-related event (assuming you can even enumerate things completely).

I'm not sure exactly what web developers have shipped that uses this.  I'm open to trying to remove but it's fairly longstanding (although not interoperable) so I expect we would turn up some examples, and we'd at least need to have a good story for alternative events they should listen to.  We can follow that path but in the meantime we may as well clean up the path that we are shipping.

Any update?

No, nothing happened yet.  Do you have something that depends on this being improved?

I have a task of going through our tests that are marked as flakey and disabled to see if any of them can get re-enabled. So this is just blocking a disabled test which hopefully isn't missing other problems.

Linux and Mac seem to be emitting 229 for *physical* key presses in some cases, which doesn't seem right to me. For example, if I go to the Keyboard Event Viewer in Chrome for Mac:
https://w3c.github.io/uievents/tools/key-event-viewer.html

and have Hangul input enabled (2-Set Korean), typing the letter 'a' produces a keydown event with keycode 229, but a keyup event with keycode 65 ('A'). I think both events should have keycode 65.

On Linux, the behavior is even more bizarre. With Hangul input enabled, typing the letter 'a' produces the same result as on Mac. However, if I then press the left arrow key, I get two additional 229 keydown events before the keydown/keyup pair with keycode 37 for the left arrow key.


It seems that at the very least, we should not be overwriting real keydown/keyup events with a fake 229 keydown. I suspect there's not a good reason to have them at all on physical keyboards. We may want to keep them for virtual keyboards where there's not a real keydown event to go with the composition change, although it seems non-ideal for web developers to be listening for these fake keydown events instead of e.g. an input event instead.

Here's an example of something that would probably break on Android without the 229 events:
https://www.outsystems.com/blog/javascript-events-unmasked-how-to-create-input-mask-for-mobile.html

"Here’s how to find the pressed key. When the keydown event is triggered, the input value doesn’t change and so you should store it then. However, if the event isn’t canceled, the input value will change. This triggers the input event and creates a new value. So if you had stored the input value before the change, you could then compare it with the new one after the change."

So developers using this approach are using the 229 keydown as a warning that the input value is about to change. Really I think they could/should be using the beforeinput event for that.

Archiving old bugs that haven't been actively assigned in over 180 days.

If you feel this issue should still be addressed, feel free to reopen it or to file a new issue. Thanks!