1880458 - Keystroke repeat works inconsistently

Status: RESOLVED DUPLICATE of bug 1880619

(Core :: Widget: Gtk, defect)

Description

[B.J. Herbison]

For the last couple of days keystroke repeat has been working inconsistently with ASan Nightly. Pressing and holding keys (including letters, backspace, and arrow keys) does not cause a consistent repeating of the key. Sometimes there is no repeat, sometimes it works slowly, sometimes it comes in bursts.

Environment: Ubuntu running XFCE.

The problem occurs in a new profile. The problem doesn't occur with Firefox release or the standard Nightly build.

The problem doesn't occur in the URL bar.

The problem occurs in the search box on google.com and the search box on bing.com.
The problem doesn't occur in the search box on yahoo.com or the search box on bugzilla.mozilla.org.

Mozregression isn't very helpful. It produces a wide range and then gives a couple dozen "Unable to find build info using the taskcluster route" messages. The information is:

 4:08.74 INFO: Last good revision: 27636a965cb6b6fb3f56596852a05e406edcc8eb (2024-02-12)
 4:08.74 INFO: First bad revision: 1dc1bad36464b230704d87cdfffa0c024bdb2ebf (2024-02-13)
 4:08.74 INFO: Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=27636a965cb6b6fb3f56596852a05e406edcc8eb&tochange=1dc1bad36464b230704d87cdfffa0c024bdb2ebf

 4:08.74 INFO: Switching bisection method to taskcluster
 4:08.74 INFO: Getting mozilla-central builds between 27636a965cb6b6fb3f56596852a05e406edcc8eb and 1dc1bad36464b230704d87cdfffa0c024bdb2ebf

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Firefox Build System::Task Configuration' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Julien Cristau [:jcristau]]

The bot is wrong.

Comment 3

[B.J. Herbison]

Not surprisingly, I don't see anything in the error console (on three sites that show the problem).

Looking at about:processes, the Nightly process uses more CPU when holding down a key but there is no obvious increase in the CPU use for the domain-specific processes.

Comment 4

[dechobarca]

Having the same issue on 124.0.1 on Linux Mint Cinnamon if that's relevant. No issues in the address bar, but on certain websites like Reddit for example, anywhere where text input is accepted, the repeat rate is inconsistent, slow, janky. It's practically unusable in this current state.

Comment 5

[fenio_px]

(In reply to dechobarca from comment #4)

Having the same issue on 124.0.1 on Linux Mint Cinnamon if that's relevant. No issues in the address bar, but on certain websites like Reddit for example, anywhere where text input is accepted, the repeat rate is inconsistent, slow, janky. It's practically unusable in this current state.

I have the same problem.
Linux Mint 21.3 - Cinnamon
Kernel 6.8.1
Firefox 124.0.1
AMD Radeon 7700XT
The problem occurs e.g. on twitter.com

Comment 6

[Matt]

I have the same problem,

Ubuntu 22.04
Linux 6.6.0-10 (hwe)
Firefox 125.0b3 (from Ubuntu Mozilla Team PPA)

Affects most text input (Google, Reddit, YouTube) but doesn't occur on mozilla.org.

Maybe a JS event handler vs Firefox issue?

Also, this occurs on a new clean profile.

Comment 7

[fenio_px]

By the way, I would like to mention that the problem does not occur in other Firefox-based browsers.
Everything works fine on Floorp Browser in the latest version 11.11.1.

Comment 8

[aaronjflores962]

Manjaro (Gnome 3, Wayland)
Linux 6.1.80.1
Firefox 124.0

Like others, affects most input fields, erratically repeating sometimes taking a couple seconds sometimes much longer between each repeat. Clean profile with no extensions after a fresh reinstall of Firefox 124.0 does not solve the issue.

Comment 9

[Triffid Hunter]

Yep, this is now affecting me in the 124.0 release.

It seems like key repeat does work, it's just incredibly slow (2-15 seconds per repeat) and with a random delay each time.

I'm confused as to why firefox is even attempting to handle this itself, shouldn't it be the DE/WM/OS's job to handle key repeat settings?

Comment 10

[Jonathan Rawle]

I also have seen this issue since upgrading to 124.0, then 124.0.1.
XFCE running on CentOS 7, X.Org X Server 1.20.4
I first noticed the issue in the Gmail editor, and also the YouTube search box. It is certainly only on a subset of sites. This comment box is fine, for example!

Comment 11

[JJ]

Having the same issue with 124.0.1 on Debian 11, it affects some web apps like Element and Gmail.

Comment 12

[John Nagle]

I'm seeing this too, but only with some web pages.
Ubuntu 22.04 LTS, Firefox 124.0 release, installed by automatic snap installation.

Effect is that holding down a key does not repeat at all.

• Succeeds here.
• Succeeds on Reddit.
• Succeeds on Hacker news.
• Fails for Rust forums.

Rust forums are using the Amber framework.

Comment 13

[Wm. A]

I tested this with Firefox 124.0.1 on Debian 12.5, where this problem occurred, and Windows 10, where it didn't. Linux typematic settings (as displayed by 'xset q' and set with 'xset r rate') are 330 ms delay / 25 repeat rate.

In some initial testing, it appeared that key repeat works normally for traditional form fields like <textarea> and <input>. This failure seemed to happen only on webpages where Javascript is processing keyboard input and updating another element (e.g. a <div>) to show whatever text the user has entered. Depending on the site, the slowdown can be barely perceptible or agonizingly long. When a key is held long enough to repeat multiple times, the rate at which characters are registered also varies. For example:

• Teams: Shortest repeat time was 11 seconds; longest was > 30 seconds, at which point I gave up.
• Jira: Initial delay of 3-4 seconds, then short periods of almost-normal performance interspersed with slightly longer delays.
• Outlook 365 message composition: Widely varying delays, but less than 5 seconds.

However, additional experimentation brought up two counterexamples: In Outlook 365, the search bar and (to a lesser extent) the Subject line, both plain <input> fields, exhibited this problem; on new.reddit.com, input is written into a <span> yet no measurable difference was noted.

Comment 14

[fenio_px]

The problem exists, we already know that, but a lot of time has passed and we have not received any official answer. A browser that works this way is practically unusable. For this reason, I switched from Firefox to Floorp because what else should I do? I'm staying with Floorp because, as it turns out, it's just good and works. I have no intention of waiting for months for such an early and easily verifiable bug to be fixed. The Firefox ESR advantage in Floorp has become crucial for me in choosing a browser.

Comment 15

[dechobarca]

(In reply to fenio_px from comment #14)

The problem exists, we already know that, but a lot of time has passed and we have not received any official answer. A browser that works this way is practically unusable. For this reason, I switched from Firefox to Floorp because what else should I do? I'm staying with Floorp because, as it turns out, it's just good and works. I have no intention of waiting for months for such an early and easily verifiable bug to be fixed. The Firefox ESR advantage in Floorp has become crucial for me in choosing a browser.

What you said sounds harsh, but I have to agree, this does make the browser unusable if you're writing any text in your browser. I've also considered switching because what else are you going to do, I can't use my browser like that.

I was able to fix the issue by installing the flatpak version, and then syncing my profile, but not everyone is going to do that, and it's sad to see the problem being neglected. I am almost sure it has something to do with settings (those in about:config) because it's definitely not extensions.

Comment 16

[Christian Holler (:decoder)]

(In reply to fenio_px from comment #14)

The problem exists, we already know that, but a lot of time has passed and we have not received any official answer. A browser that works this way is practically unusable.

Are you talking about this bug specifically? Please note that this bug is about the ASan Nightly build of Firefox, not the official Firefox. Are you encountering this problem on official non-ASan Firefox?

Comment 17

[JJ]

(In reply to Christian Holler (:decoder) from comment #16)

(In reply to fenio_px from comment #14)

The problem exists, we already know that, but a lot of time has passed and we have not received any official answer. A browser that works this way is practically unusable.

Are you talking about this bug specifically? Please note that this bug is about the ASan Nightly build of Firefox, not the official Firefox. Are you encountering this problem on official non-ASan Firefox?

Not the OP, but I can confirm I'm having this issue on the official build.

Comment 18

[Yukinoroh[:Yukinoroh]]

I have this issue on the official build too.
See bug #1887605 for details.
Wm. A. provided a clue; I tried to disable Javascript and the problem does not occur. So it seems to be Javascript related.

Comment 19

[Gian-Carlo Pascutto [:gcp]]

Removing the ASAN Nightly tag as most of you don't actually seem to be on ASAN Nightly, and I don't see much indication it is specific (ASAN Nightly has very different performance from normal builds so seeing a bit of slowdown there wouldn't be unexpected).

Because it's clear a lot of users on normal builds are affected, rising to S2.

Comment 20

[Gian-Carlo Pascutto [:gcp]]

Mozregression isn't very helpful.

Thanks for running it anyway - I'm not sure if that error can't be worked around (or would be fixed by updating mozregression?), but I can make an educated guess based on it.

Comment 22

[fenio_px]

(In reply to Christian Holler (:decoder) from comment #16)

Are you talking about this bug specifically? Please note that this bug is about the ASan Nightly build of Firefox, not the official Firefox. Are you encountering this problem on official non-ASan Firefox?

Yes. Official stable version 124.0.1

Comment 23

[Gian-Carlo Pascutto [:gcp]]

As per the bug this was duped to, this will be fixed in the next Nightly and uplifted to betas of Firefox 125.