Duplicate key events when typing fast

RESOLVED WORKSFORME

Status

()

defect
P5
normal
RESOLVED WORKSFORME
5 months ago
a month ago

People

(Reporter: mkaply, Unassigned)

Tracking

({regression})

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox63 wontfix, firefox64 wontfix, firefox65 fix-optional, firefox66 affected)

Details

(URL)

(Reporter)

Description

5 months ago
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.
(Reporter)

Updated

5 months ago
Duplicate of this bug: 1421805
(Reporter)

Updated

5 months ago
Duplicate of this bug: 1419376
Like, there is repeated keypress then. Just press any key for a long time.
(Reporter)

Comment 5

5 months ago
> 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.
(Reporter)

Comment 7

5 months ago
> 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]

Comment 10

5 months ago
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
(Reporter)

Comment 12

5 months ago
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.
(Reporter)

Comment 13

5 months ago
It looks like it regressed between November 5 and November 6 2016
(Reporter)

Comment 15

5 months ago
> 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

Comment 17

5 months ago
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?
Flags: needinfo?(mozilla)
(Reporter)

Comment 19

5 months ago
I see the same results as Alice. 

1478309966 good
1478310501 bad (lots of duplication)
Flags: needinfo?(mozilla)
(Reporter)

Comment 20

4 months ago
It was definitely enabling the GPU process that caused this.

Flipping that pref fixes it.
Blocks: 1314133
(Reporter)

Comment 21

4 months ago
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)
(Reporter)

Comment 24

4 months ago
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.
(Reporter)

Comment 25

3 months ago

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.

Status: NEW → RESOLVED
Last Resolved: 3 months ago
Flags: needinfo?(mozilla)
Resolution: --- → WORKSFORME
Component: Event Handling → User events and focus handling
Product: Core → Core
You need to log in before you can comment on or make changes to this bug.