Bugzilla

Comment 1

•

10 years ago

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

Comment 2

•

10 years ago

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)

H. Nüstedt

Reporter

Comment 3

•

10 years ago

I don't know if it helps:

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

Jason Rohrer

Comment 4

•

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

Tracy Walker [:tracy]

Updated

•

8 years ago

Priority: -- → P4

Whiteboard: tpi:+

Maciek Sakrejda

Comment 5

•

8 years 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?

Maciek Sakrejda

Comment 6

•

8 years 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...

https://youtu.be/aG--09h2mcY

Comment 7

•

5 years ago

I have been experiencing this bug in Firefox 68.0.1+build1-0ubuntu0.18.04.1 .

We recently switched to an Integrated Library System (Koha) at my library that is a web app. I have experienced this behavior of dropping duplicate characters (I have seen this happen with barcodes that have multiple nines (99) and multiple zeros (000). This behavior exists across two different barcode scanners from two different manufacturers. I only get the scanning errors with Firefox. With gedit, libreoffice, or chromium, I do not get the error.

I'm including a link to a youtube video of the problem happening. There are two instances of Firefox dropping consecutive digits that are the same. The first scan if the ISBN of a book. When it fails, I immediately rescan getting the correct number and the search returns the desired results. The second set of scans if from the item's library barcode. Again, the second attempt is successful.

Comment 8

•

5 years ago

(In reply to RonH from comment #7)

I have been experiencing this bug in Firefox 68.0.1+build1-0ubuntu0.18.04.1 .

We recently switched to an Integrated Library System (Koha) at my library that is a web app. I have experienced this behavior of dropping duplicate characters (I have seen this happen with barcodes that have multiple nines (99) and multiple zeros (000). This behavior exists across two different barcode scanners from two different manufacturers. I only get the scanning errors with Firefox. With gedit, libreoffice, or chromium, I do not get the error.

I'm including a link to a youtube video of the problem happening. There are two instances of Firefox dropping consecutive digits that are the same. The first scan if the ISBN of a book. When it fails, I immediately rescan getting the correct number and the search returns the desired results. The second set of scans if from the item's library barcode. Again, the second attempt is successful.

https://youtu.be/aG--09h2mcY

Would you be able to use the steps from comment #2 to provide more debug info here? (see below)

(In reply to Karl Tomlinson (:karlt) from comment #2)

Running a Nightly or debug build with MOZ_LOG_MODULES=WidgetFocus:5 in the
environment would log enough to determine whether Gecko is getting all the
release events.

Flags: needinfo?(rhouk)

Comment 9

•

5 years ago

(In reply to :Gijs (he/him) from comment #8)

(In reply to RonH from comment #7)

I have been experiencing this bug in Firefox 68.0.1+build1-0ubuntu0.18.04.1 .

We recently switched to an Integrated Library System (Koha) at my library that is a web app. I have experienced this behavior of dropping duplicate characters (I have seen this happen with barcodes that have multiple nines (99) and multiple zeros (000). This behavior exists across two different barcode scanners from two different manufacturers. I only get the scanning errors with Firefox. With gedit, libreoffice, or chromium, I do not get the error.

I'm including a link to a youtube video of the problem happening. There are two instances of Firefox dropping consecutive digits that are the same. The first scan if the ISBN of a book. When it fails, I immediately rescan getting the correct number and the search returns the desired results. The second set of scans if from the item's library barcode. Again, the second attempt is successful.

https://youtu.be/aG--09h2mcY

Would you be able to use the steps from comment #2 to provide more debug info here? (see below)

(In reply to Karl Tomlinson (:karlt) from comment #2)

Running a Nightly or debug build with MOZ_LOG_MODULES=WidgetFocus:5 in the
environment would log enough to determine whether Gecko is getting all the
release events.

I would be happy to try this. I have downloaded a nightly, but I'm not entirely sure how to get the log file. In my terminal I've entered

"set NSPR_LOG_MODULES=WidgetFocus:5"

and then run firefox.

Could you provide some guidance on how I should do this? Thank you.

Flags: needinfo?(rhouk) → needinfo?(gijskruitbosch+bugs)

Comment 10

•

5 years ago

(In reply to RonH from comment #9)

I would be happy to try this. I have downloaded a nightly, but I'm not entirely sure how to get the log file. In my terminal I've entered

"set NSPR_LOG_MODULES=WidgetFocus:5"

and then run firefox.

You'd want to run firefox while the environment variable is set. You can do this from the commandline if you know the path to firefox, ie:

NSPR_LOG_MODULES=WidgetFocus:5 /some/path/to/firefox

in your terminal should work (just leave a space after the '5' and before the start of the path to firefox)

If that somehow doesn't work, you can also try just starting Firefox, and then:

go to about:networking (you may need to click through the warning)
go to the "Logging" section on the left
In the "logging modules" field put "WidgetFocus:5" (without the quotes), and click 'set log modules'
in the "current log file" field, put a path to a new file of your choice, click "set log file"

(Note: Firefox will generate more than one file based on the file path you specify, for parent/child processes, so it may be helpful to just create an empty directory to put the logfiles in, to make it easier to stick them all in an archive to attach here)

check content is being written to the file(s) specified
reproduce the issue.

Let me know if you get stuck on any of this.

Flags: needinfo?(gijskruitbosch+bugs) → needinfo?(rhouk)

Comment 11

•

5 years ago

Attached file Firefox nightly logs — Details

Hello,

I am attaching the requested log files. I had to scan the barcode several times before the error occurred. Once the error occurred, I closed the browser. The error was the second "9" in the barcode 34199000915025 was dropped.

Please let me know if there is anything else I can help with.

Flags: needinfo?(rhouk) → needinfo?(gijskruitbosch+bugs)

Comment 12

•

5 years ago

•

Edited

Thanks! I'm not an expert in the relevant bits of Firefox - hopefully Karl or Martin can take a look and draw some conclusions from what's going on in https://bugzilla.mozilla.org/attachment.cgi?id=9086525 .

Flags: needinfo?(stransky)

Flags: needinfo?(karlt)

Flags: needinfo?(gijskruitbosch+bugs)

Comment 13

•

5 years ago

Two observations from the log:

One: There are many events logged that look consistent with a combination of two keys (e.g. Shift+x or similar):

[Parent 4982: Main Thread]: D/WidgetFocus OnKeyPressEvent [0x7f60c0de7400]
[Parent 4982: Main Thread]: D/WidgetFocus OnKeyPressEvent [0x7f60c0de7400]
[Parent 4982: Main Thread]: D/WidgetFocus OnKeyReleaseEvent [0x7f60c0de7400]
[Parent 4982: Main Thread]: D/WidgetFocus OnKeyReleaseEvent [0x7f60c0de7400]

Two: There are about 37 sequences each of about 40 OnKeyPressEvent without any intermediate OnKeyReleaseEvent.

That would be consistent with holding down a key for autorepeat, but it makes me wonder whether the barcode reader is not generating the KeyRelease events.

I would run xev to log what the barcode reader is producing.

Flags: needinfo?(karlt)

Comment 14

•

5 years ago

Attached file firefox_log_20190820.tar.xz — Details

Hello Karl,

I am attaching another set of logs. Like last time and I had to do several scans before I got the error. The second 9 in the barcode 34199001755933 was dropped again (I've had other numbers in the past).

There is also an xinput log in the attachment as well recording info from the scanner. I used the command

input test-xi2 9 > xinput.log

to generate the log.

I wasn't sure what I was doing incorrectly with xev, I was able to attach it to my browsers window, but it didn't look like it was recording input from the scanner.

Flags: needinfo?(karlt)

Martin Stránský [:stransky] (ni? me)

Comment 15

•

5 years ago

I don't know what is happening, sorry.

The latest Firefox log looks very different from the last one. There are no obvious long autorepeat sequences, but there are some 4-key combinations. I can't explain why there are 2293 KeyRelease events for the 2288 KeyPress events.

The xinput.log seems to show that there are matching press/release pairs.

By default, Firefox behaves as if GDK_CORE_DEVICE_EVENTS=1 is in the environment. This can be reverted by putting MOZ_USE_XINPUT2=1 in the environment, to see whether that helps.

Flags: needinfo?(karlt)

Updated

•

5 years ago

Flags: needinfo?(stransky)

Priority: P4 → P3

Comment 16

•

5 years ago

I can confirm this. Been working with a barcode scanner today, took me a while to realize that it's only in Firefox where I'm loosing characters. I'm running 68.0.2+build1-0ubuntu0.18.04.1. First I tried:

Firefox and a web application with a little bit of (unobtrusive) JavaScript: I'm missing characters when scanning barcodes
tried with gedit and a Java-based IDE: no missing characters at all

Sample result when scanning the same barcode again and again:

6943_780_3118
6943478003118
6943478003118
69434780031_8
6943478003118
6943478003118
6943478003118
6943478003118
6943478003118
6943478003118
6943478003118
6943478003118
6943478003118
6943_78003118
6943478003118
6943478003118
6943_78003118
6943478003118
6943478003118
6943478003118
6943_78003118
6943478003118
69434780031_8
69434780031_8
6943478003118
6943478003118
6943_78003118
6943478003118
69434780031_8
69434780031_8

Didn't try other bar codes. As you can see, there is a double 0 (zero) and a double 1 in this code. Again and again I'm missing either one of those double-characters or the number 4 - which also exists twice, but with a different number in between.

For better readability I replaced the missing characters with underscores. Discovered this bug report, wrote a stupid little sample HTML page, no JavaScript, fresh Firefox instance, no other open tabs:

<html><body><form><textarea></textarea></form></body></html>

Same behavior, loosing characters. The same test with MOZ_USE_XINPUT2=1 works fine, experienced no issues when doing so.

Cheers,
Thomas

Comment 17

•

5 years ago

One more note: disabled all Add-ons, same behavior. And the effect is not limited to <textarea />, also my <input type="text" />-elements are missing characters.

Comment 18

•

5 years ago

Did another short test with xinput test. Got the following input in the text area...

694347800311
6943478003118

...while xinput showed the following:

key press   15 
key release 15 
key press   18 
key release 18 
key press   13 
key release 13 
key press   12 
key release 12 
key press   13 
key release 13 
key press   16 
key release 16 
key press   17 
key release 17 
key press   19 
key release 19 
key press   19 
key release 19 
key press   12 
key release 12 
key press   10 
key release 10 
key press   10 
key release 10 
key press   17 
key release 17 
key press   36 
key release 36 
key press   15 
key release 15 
key press   18 
key release 18 
key press   13 
key release 13 
key press   12 
key release 12 
key press   13 
key release 13 
key press   16 
key release 16 
key press   17 
key release 17 
key press   19 
key release 19 
key press   19 
key release 19 
key press   12 
key release 12 
key press   10 
key release 10 
key press   10 
key release 10 
key press   17 
key release 17 
key press   36 
key release 36

That's the exact same sequence twice, with all press/release events in the right order - but Firefox misses a character during the first attempt. At least that's what it looks like to me.

Comment 19

•

5 years ago

Can you see whether this bug still reproduces with GTK_IM_MODULE=gtk-im-context-simple in the environment, please?

Comment 20

•

5 years ago

(In reply to Thomas from comment #16)

Same behavior, loosing characters. The same test with MOZ_USE_XINPUT2=1 works fine, experienced no issues when doing so.

If gedit is run with GDK_CORE_DEVICE_EVENTS=1 in the environment, does it reproduce?

Comment 21

•

5 years ago

(In reply to Karl Tomlinson (:karlt) from comment #19)

Can you see whether this bug still reproduces with GTK_IM_MODULE=gtk-im-context-simple in the environment, please?

It does not reproduce with GTK_IM_MODULE=gtk-im-context-simple

If gedit is run with GDK_CORE_DEVICE_EVENTS=1 in the environment, does it reproduce?

It does not, gedit with GDK_CORE_DEVICE_EVENTS=1 works fine.

Short summary:

NOK: firefox --safe-mode scan.html
OK: GTK_IM_MODULE=gtk-im-context-simple firefox --safe-mode scan.html
OK: MOZ_USE_XINPUT2=1 firefox --safe-mode scan.html
OK: gedit
OK: GDK_CORE_DEVICE_EVENTS=1 gedit

Comment 22

•

5 years ago

Thanks. It sounds like the IME is involved here, but somehow the interaction with the IME differs between gedit and Firefox.

Comment 23

•

5 years ago

Sounds like that we mark some key events of 0 as "repeated" and drop some repeated keys in content process to yield its main thread resource.

Do you reproduce it with URL bar or search bar? They are in the parent process so that any key events won't be dropped.

And also what keydown and keypress events are fined on the test suite when you input all 0 bar code? I guess repeat is checked and code values are same.

Comment 24

•

5 years ago

(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(no pain of the broken bone, but the corset blocks me to concentrate) from comment #23)

Do you reproduce it with URL bar or search bar? They are in the parent process so that any key events won't be dropped.

I can reproduce it in the search bar, when generating the very same code multiple times (issues a search request every time) I'm easily able to see codes with missing numbers/characters.

And also what keydown and keypress events are fined on the test suite when you input all 0 bar code? I guess repeat is checked and code values are same.

Not really. Here some tests, all with --safe-mode:

No special ENV settings, correct characters: events_normal.png
Extreme example, missing three characters: events_normal_missing_three.png
Using MOZ_USE_XINPUT2=1: events_xinput.png

Please let me know whether I should repeat the test with all zeros.

Comment 25

•

5 years ago

Hello,

I would also like to report that I have not been experiencing scanner errors since putting MOZ_USE_XINPUT2=1 in as an environment variable.

Eric

Comment 26

•

5 years ago

I've been experiencing the same thing. Firefox 68.0.1 on Gentoo. I actually bought a new keyboard for my laptop thinking the keys were starting to die. I also get some repeated characters from time to time which made me think it was the old problem I was having a few years ago that involved the kernel's priority for the keyboard. That's actually how I found this and realized this might well be the culprit.

Comment 27

•

5 years ago

(In reply to Thomas from comment #24)

Extreme example, missing three characters: events_normal_missing_three.png

Oh, I missed to check this result. According to this result, we handled some missing character inputs as IME composition (but failed of course since it's not actual composition).

Keywords: inputmethod

Comment 28

•

5 years ago

And it seems that we receive key events different order than the log in comment 18 because the key events whose key value is Process are handled in completely broken order (you can know which key causes the Process key events with the code value like Digit8).

Comment 29

•

5 years ago

Could somebody attach a log file of the main process? It can be logged with setting Current Log Modules: in about:networking to KeymapWrapperWidgets:5,nsGtkIMModuleWidgets:5,sync. But please be careful, the log file will contain any input from keyboard so that you shouldn't type anything your privacy like passwords (might be logged passwords if you input them with password manager).

Comment 30

•

4 years ago

Moving all open keyboard/IME handling bugs to DOM: UI Events & Focus Handling component.

Component: Widget: Gtk → DOM: UI Events & Focus Handling

Updated

•

4 years ago

Summary: Firefox is missing characters in fast-typing applications → [GTK] Firefox is missing characters in fast-typing applications