Firefox is missing characters in fast-typing applications

UNCONFIRMED
Unassigned

Status

()

Core
Widget: Gtk
P4
normal
UNCONFIRMED
3 years ago
10 months ago

People

(Reporter: H. Nüstedt, Unassigned)

Tracking

({testcase})

33 Branch
x86_64
Linux
testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: tpi:+)

Attachments

(1 attachment)

(Reporter)

Description

3 years ago
Created attachment 8522771 [details]
test_firefox.sh - Testing-Script

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/33.0.1750.152 Safari/537.36

Steps to reproduce:

I am using a barcode-reader with no inter-character delay. When I try to scan a barcode with a number of leading zeros Firefox often misses some zeros. If I scan into any other application (gedit, Chromium) this does not happen.

For testing supposes I wrote the following script using xdotool:
-------------------------
#!/bin/bash
sleep 5
for i in {1..30}
do
  SENTENCE1="0000000000"
  SENTENCE2="1234567890"

  xdotool type $SENTENCE1
  xdotool key "Return"

  xdotool type $SENTENCE2
  xdotool key "Return"
done
--------------------

In the initial 5-second-sleep I am placing the cursor to a simple HTML-Textarea, in this special case I used this one:
http://de.selfhtml.org/html/formulare/anzeige/textarea.htm


Actual results:

When the script has ended the following is displayed in the textarea:
-------------------------
000000000
1234567890
0000000000
1234567890
00000000
1234567890
00000000
1234567890
00000000
1234567890
0000000000
1234567890
0000000000
1234567890
00000000
1234567890
0000000000
1234567890
00000000
1234567890
000000000
1234567890
000000000
1234567890
00000000
1234567890
0000000000
1234567890
0000000
1234567890
000000000
1234567890
000000000
1234567890
0000000000
1234567890
00000000
1234567890
0000000000
1234567890
00000000
1234567890
0000000000
1234567890
000000000
1234567890
0000000000
1234567890
000000000
1234567890
00000000
1234567890
000000000
1234567890
00000000
1234567890
000000000
1234567890
000000000
1234567890
-----------------------


Expected results:

If I place the cursor in gedit, I get the following, expected Output:
-------------------
0000000000
1234567890
0000000000
1234567890
0000000000
1234567890
0000000000
1234567890
0000000000
1234567890
0000000000
1234567890
0000000000
1234567890
0000000000
1234567890
0000000000
1234567890
0000000000
1234567890
0000000000
1234567890
0000000000
1234567890
0000000000
1234567890
0000000000
1234567890
0000000000
1234567890
0000000000
1234567890
0000000000
1234567890
0000000000
1234567890
0000000000
1234567890
0000000000
1234567890
0000000000
1234567890
0000000000
1234567890
0000000000
1234567890
0000000000
1234567890
0000000000
1234567890
0000000000
1234567890
0000000000
1234567890
0000000000
1234567890
0000000000
1234567890
0000000000
1234567890
------------------------

Updated

3 years ago
Component: Untriaged → Untriaged
Product: Firefox → Core
Karl, can you shed light on what's going on here or redirect to someone who can? :-)

(I'm wondering if this is related to the polling in bug 1097114 / bug 1077652)
Component: Untriaged → Widget: Gtk
Flags: needinfo?(karlt)
Keywords: testcase
I don't know what's happening here.  My best guess is that the key events generated by xdotool might all have the same timestamp, which might be leading to something (I don't know what) removing the intermediate KeyRelease events.  If that is happening, then Gecko's widget code will interpret the series of events as autorepeat, and skip events if Gecko cannot keep up.  However, the key events should have matching Press/Release pairs, and so this behavior is not expected.

Running a Nightly or debug build with NSPR_LOG_MODULES=WidgetFocus:5 in the environment would log enough to determine whether Gecko is getting all the release events.
Flags: needinfo?(karlt)
(Reporter)

Comment 3

3 years ago
I don't know if it helps:

I am not able to reproduce this bug on an Android 4.4 platform.

Comment 4

2 years ago
I'm seeing the same behavior now in FF 43.0 with my YubiKey (usb one-time-password generator), but I recently upgraded Ubuntu from Feisty (very old) to Trusty.  It never happened in Feisty, even with FF 43.

However, in all other applications besides FF, no key presses are missed (tried Leafpad and LXTerminal and Midori browser).

Also, I notice that the YubiKey input comes out slow and jerky in FF, whereas in other applications, it comes out fast and smooth (one character at a time).  In FF, the characters show up as jerky clumps.

In Chromium, no characters are missed, but the fast input is jerky and appears in a few clumps instead of one character at a time.
Priority: -- → P4
Whiteboard: tpi:+

Comment 5

a year ago
I'm seeing something very similar to Jason in Firefox 49.0 on Ubuntu 16.04: about half the time, Firefox misses at least one character (sometimes two or three) from my Yubikey input, leading to a frustrating experience because my login is rejected with "invalid two-factor code" (suggesting that there's something wrong with my Yubikey itself).

Like Jason, I haven't had any problems in Chromium.

As workaround, is there a different recommended mechanism for a device acting as a keyboard (which I believe is what the Yubikey does) to enter text into a field in Firefox more reliably?

Comment 6

10 months ago
For what it's worth, I've been able to work around this by using a password input instead of text--password does not seem to drop characters for some reason...
You need to log in before you can comment on or make changes to this bug.