When you type very fast, Firefox gets duplicate key events. Chrome (and other browsers) do not. To recreate: go to https://embed.plnkr.co/aXoLcM8oCx583xWC2RlT/ 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.

Likely caused by https://bugzilla.mozilla.org/show_bug.cgi?id=1390044

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.

Not a qf. And as far as I things are working as expected.

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.

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

FWIW, I can reproduce the issue on Windows10 if I removed a for loop from https://embed.plnkr.co/aXoLcM8oCx583xWC2RlT/ good build: https://archive.mozilla.org/pub/firefox/tinderbox-builds/mozilla-inbound-win32/1478549667/ bad build: https://archive.mozilla.org/pub/firefox/tinderbox-builds/mozilla-inbound-win32/1478550687/ Regression window: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=d19cffeae1febc6d669a024340de25228e544475&tochange=24d97dc514d4b8fe608e9aee7527615c1e613606 it seems Bug 1300659 trigger the bug.

> it seems Bug 1300659 trigger the bug. Thank you! And that maps to right around when I was seeing it.

Further investigation, Umm, type fast enough, the regression window is https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=c04f84afb1bd6b3ea372164012735de6c8f2d582&tochange=b4ade2b0841c5825968f34752d86ee09507a0a9f Triggered by: b4ade2b0841c David Anderson — Enable the GPU process for Nightly Windows users. (bug 1314133, r=milan) good build: https://archive.mozilla.org/pub/firefox/tinderbox-builds/mozilla-inbound-win32/1478309966/ bad build: https://archive.mozilla.org/pub/firefox/tinderbox-builds/mozilla-inbound-win32/1478310501/ 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?

I see the same results as Alice. 1478309966 good 1478310501 bad (lots of duplication)

It was definitely enabling the GPU process that caused this. Flipping that pref fixes it.

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).

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?

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.