Closed Bug 1504692 Opened 4 years ago Closed 3 years ago

Duplicate key events when typing fast


(Core :: DOM: UI Events & Focus Handling, defect, P5)




Tracking Status
firefox63 --- wontfix
firefox64 --- wontfix
firefox65 --- fix-optional
firefox66 --- affected


(Reporter: mkaply, Unassigned)




(Keywords: regression)

When you type very fast, Firefox gets duplicate key events. Chrome (and other browsers) do not.

To recreate:

go to

Put focus in the entry field. Type 1234567890 very fast (Easiest to do on a Mac by just dragging your finger across the number keys).

Notice that randomly, you get an extra number.
Duplicate of this bug: 1421805
Duplicate of this bug: 1419376
Like, there is repeated keypress then. Just press any key for a long time.
> Like, there is repeated keypress then. Just press any key for a long time.

It's not a repeated keypress. The keys are pressed extremely fast and not held down.
On Chrome key input handling seems to be way jankier with that test.
> On Chrome key input handling seems to be way jankier with that test.

Yeah, it waits until typing is done to put anything in.

Oddly Safari is fast.
Blink's timers are slower than in Gecko, IIRC. So, timer may very well fire before keypress.
So both the timer and keypress listener end up calling appendToOutput.
Priority: -- → P2
Whiteboard: [qf]
Not a qf. And as far as I things are working as expected.
Whiteboard: [qf]
According with Bug 1421805 Comment#1 and Bug 1419376 Comment#7
this is regressed by bug 1390044.
As far as I see, the behavior could happen even before bug 1390044, and I've been told it does.
This is more likely a change from e10s.
No longer blocks: 1390044
I agree with Olli.

I was able to recreate this back to November 2016. (I'm still going farther back).

With the older builds, just typing one character a few times is enough to get the repeat.

FYI, A better way to recreate is just to bang really fast on some keys while in the entry field.

When you are done, the text below should match the entryfield exactly. If it doesn't, you have the bug.

Doing it this way avoids the problem where holding a key down too long repeats.
It looks like it regressed between November 5 and November 6 2016
> it seems Bug 1300659 trigger the bug.

Thank you! And that maps to right around when I was seeing it.
Blocks: 1300659
Duplicate of this bug: 1504914
Further investigation,
Umm, type fast enough, the regression window is

Triggered by: b4ade2b0841c	David Anderson — Enable the GPU process for Nightly Windows users. (bug 1314133, r=milan)

good build:
bad build:

Could someone double check the regression window with these good/bad build of Comment 14 and Comment 16.
Mike, can you verify the builds that Alice linked to?
Flags: needinfo?(mozilla)
I see the same results as Alice. 

1478309966 good
1478310501 bad (lots of duplication)
Flags: needinfo?(mozilla)
It was definitely enabling the GPU process that caused this.

Flipping that pref fixes it.
Blocks: 1314133
VMWare repinged us on this as an issue with their VSphere web client.

While they put in a workaround, they want to know when we are going to fix.

This seems to fall squarely into the "we broke enterprise software" bucket.

I'm having trouble getting any traction on this though inside Mozilla.

NIing Mike Taylor to see if he has any advice.

(Side note - while enabling the GPU process broke this originally, clearly there are other things going on because it is repeatable on Mac. We need someone who really understands eventing to figure out what is going on here).
Flags: needinfo?(miket)
My guess here is that the web site assumes keydown and keypress happening during the same task, and no spec defines that. In e10s those are in separate tasks.
The example script clearly is buggy on that, it lets timeout to fire between keydown and keypress and execute appendToOutput on both cases. (it is unclear to me what the code is trying to do)
Mike, can we get access to the VSphere web client to investigate what exactly they're doing?
Flags: needinfo?(miket) → needinfo?(mozilla)
They've worked around the problem in the latest vsphere client. The plunker above is the code they are using.

I'll see if I can get more info.

They (VMWare) are now saying their workaround is good enough and that we can close the issue for now.

I'm still concerned that we have a key difference between Firefox and Chrome.

We should at least keep an eye out to see if anyone else runs into this.

Closing for now.

Closed: 3 years ago
Flags: needinfo?(mozilla)
Resolution: --- → WORKSFORME
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.