1673362 - On listen keydown/keyup, sometimes the detection of event.ctrlKey fails.

Status: NEW

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

Description

[ger.benjamin]

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

Steps to reproduce:

On adding a eventListener on the Document object to listen 'keydown' (or keyup) event, I've seen that event.ctrlKey flag is not always "true" when I press the "ctrl" key.

You can reproduce the issue here: https://codepen.io/ger-benjamin/pen/ZEOeyRb

( Or copy paste and adapt: https://developer.mozilla.org/en-US/docs/Web/API/Document/keydown_event )

I use Firefox Browser 82.0 (64 bits) on Ubuntu 18.04.5 LTS

Actual results:

~10% of the time the event.ctrlKey flag value is false instead of true.
The ctrl.key is always 'Control' which is the correct behaviour.

Expected results:

If I press the ctrl key, I expect that the event.ctrlKey value is always true.

Comment 1

[Alin Ilea, Desktop QA]

Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:82.0) Gecko/20100101 Firefox/82.0

Hi,

I have managed to reproduce it on Release version 82.0.2, Beta 83.0b6 and latest Nightly 84.0a1 (2020-10-30) using Ubuntu 18.04.
Further, I will move this over to a component so developers can take a look over it. If this is not the correct component please feel free to change it to an appropriate one.
Note that the issue is not reproducible on Windows 10.

Thanks for your input.

Comment 2

[Anne (:annevk)]

Masayuki, is this something you can look at?

Comment 3

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

I cannot reproduce this bug on Ubuntu 20.10 (I'll check it on LTS, later).

X and GTK/GDK notify modifier flag change after KeyPress and KeyRelease events of modifier keys, different from the DOM spec. Therefore, we do hack for solving this with checking the event queue. So, we know it sometimes not working as expected if the queue has another event.
https://searchfox.org/mozilla-central/rev/a5d9abfda1e26b1207db9549549ab0bdd73f735d/widget/gtk/nsGtkKeyUtils.cpp#1715-1739

Reporter:

1. Do you see unexpected result when you press a Ctrl key? Or a key with pressing Ctrl key?
2. Do you use IME and/or some keyboard utilities which may put another event into the queue?

(And you can test is in https://w3c.github.io/uievents/tools/key-event-viewer.html to see the detail of the events.)

Comment 4

[ger.benjamin]

Hi Masayuki Nakano,

Thanks for your questions:

For the first question:

Yes, I've seen something.:
On Firefox, after pressing and releasing the ctrl key once I get this result:
(Modifier - ctrl flag is on the KeyUp)

X	EventType	Modifiers - getModifierState	Modifier - ctrl
2	Keyup	Control, NumLock	True
1	KeyDown	NumLock	False

And on chrome :
(Modifier - ctrl flag is on the KeyDown !)

X	EventType	Modifiers - getModifierState	Modifier - ctrl
2	Keyup	NumLock	False
1	KeyDown	Control, NumLock	True

That could explain the issue in my example.
So it's maybe not a bug, but I still think is not the standard behavior and can lead to error.

For the second question:

No, I don't use one.

Comment 5

[ger.benjamin]

I've also tried on my old Windows 7 with Edge, Chrome and Firefox.
And also on MXLinux 19.2 (Debian), with Chrome and firefox.
I always get the ctrl flag on the KeyDown, and not on the keyUp as on Firefox's Ubuntu.

So this issue looks restricted to Ubuntu, or Ubuntu 18.

Comment 6

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

Sounds like that we fail the hack for modifier key state on Linux:
https://searchfox.org/mozilla-central/rev/b741ddde6c678ca7025858952202d20664491555/widget/gtk/nsGtkKeyUtils.cpp#1738-1809

The native keyboard events do not contain the modifier state at key press, and contain it at key release of modifier keys. Therefore, we compute it at here. We need to check the log here when it's reproduced.

You can get the log with MOZ_LOG=KeyboardHandler:3,sync and launching Firefox from the terminal or set MOZ_LOG_FILE to path to the log file.

Comment 7

[Eevee (Evelyn Woods) [:eevee]]

I'm also experiencing this on Firefox 118, using Arch (with X). When I first tried the test, ctrlKey was false about half the time.

But curiously, I can't reproduce it immediately after starting Firefox (which makes the logging difficult). I do have A Lot of tabs open, and a number of them are naturally loaded over the course of a session, so it seems like the GDK workaround might become flakier as Firefox itself gets... busier.