When keydown event registered the control key being down, mousemove will register once ctrlKey=false, then ctrlKey=true
Categories
(Core :: DOM: UI Events & Focus Handling, defect)
Tracking
()
People
(Reporter: pimschreurs, Unassigned)
Details
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:105.0) Gecko/20100101 Firefox/105.0
Steps to reproduce:
With the following JS code, move your mouse a lot (make circles or something) and press the control key repeatedly:
document.addEventListener('keydown', e => {
if (e.key === 'Control') {
console.log('ctrl key down!')
}
})
document.addEventListener('mousemove', e => {
console.log('ctrl key down?', e.ctrlKey)
})
Actual results:
In console I at first see this being logged several times:
ctrl key down? false
ctrl key down!
ctrl key down? true
But later, while still moving the mouse like a fanatic, the pattern becomes this:
ctrl key down? false
ctrl key down!
ctrl key down? false
ctrl key down? true
Expected results:
Consistently:
ctrl key down? false
ctrl key down!
ctrl key down? true
Comment 1•3 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::DOM: UI Events & Focus Handling' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
Comment 2•3 years ago
|
||
I wasn't able to reproducible this on Ubuntu 20.04 or MacOS 11.
The results were consistent on both OSes.
Could you please check if this also occurs in troubleshoot mode? Here is a link that can help:
https://support.mozilla.org/en-US/kb/diagnose-firefox-issues-using-troubleshoot-mode#w_how-to-start-firefox-in-troubleshoot-mode
Thanks!
Updated•3 years ago
|
I've just tried it in troubleshoot mode on Ubuntu and the results are unfortunately unchanged.
Regarding the OSes: I'm experiencing this both on Ubuntu 22.04 and Windows 10. I also asked a coworker to try it out, who is using Ubuntu 18, and also he was able to reproduce it.
This may sound silly, but for how long did you move your mouse and press control? Have you tried different 'rhythms'/timings? Oh, and when you pressed control, did the page you tried it on actually have focus? Because when I asked my coworker, he forgot to give it focus.
Comment 4•3 years ago
|
||
hmm, it's not clear to me about why this is an issue. Why would you expect the result be such consistent?
My usage of the word "consistently" may not have been the best, but the point was that the expected behavior happened sometimes, while I expect the expected behavior to happen always.
Anyway, I don't know how to answer that question. So let me rephrase my issue.
Right after pressing ctrl while moving the mouse, the following happens sometimes:
keydownis triggered withe.key === "Control"mousemoveis triggered withe.ctrlKey === false(even though the key is down as per the previous trigger, and I haven't released the key)mousemoveis triggered withe.ctrlKey === true
If I had to make an educated guess, it seems like some sort of race condition somewhere, where a mouse move is sometimes processed before the key press, but always triggered after the key press is triggered.
Anyway, I've worked around this issue by not relying on e.ctrlKey and keep track of whether the key is pressed by listening to keydown and keyup events, so for me this is not a big issue anymore.
But regardless, I'd still consider this a bug, since it literally returns "control key is not pressed" when it clearly is (albeit for a single 'tick'). I don't encounter this in Chrome, for example. (Haven't tried any other browsers, though)
Description
•