Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at
Bug 1693091 - [regression] [wayland] key presses register multiple times in URL bar and forms
Summary: [regression] [wayland] key presses register multiple times in URL bar and forms
Alias: None
Product: Fedora
Classification: Fedora
Component: mutter
Version: 30
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Florian Müllner
QA Contact: Fedora Extras Quality Assurance
: 1693911 (view as bug list)
Depends On:
Blocks: ffwayland
TreeView+ depends on / blocked
Reported: 2019-03-27 07:15 UTC by Dimitris
Modified: 2020-03-02 12:02 UTC (History)
18 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2019-09-14 07:15:02 UTC
Type: Bug

Attachments (Terms of Use)

Description Dimitris 2019-03-27 07:15:20 UTC
Description of problem:

In the URL bar and on forms for which there is matching history, the first keystroke takes several seconds to register, and results in multiple key events with the letter being entered several times.

Version-Release number of selected component (if applicable):


How reproducible:

Every time

Steps to Reproduce:
1. Open FF under Wayland, new tab.
2. In the URL bar, type a letter for a URL that is present in history.
3. There is a long pause (up to 3-4 seconds), followed by the letter being copied into the URL bar several times (seen up to 4).
4. After carefully deleting all but the first copies of the letter, subsequent letters appear immediately and history matching works as ususal.

Actual results:

First letter takes too long to match any history and results in spurious repetition.

Expected results:

Until v65 URL bar (and forms with saved content) used to respond instantly form the first letter.

Additional info:

I do have two keyboards installed, can this upstream be the issue?

Comment 1 Dimitris 2019-03-27 19:58:05 UTC
Issue persisted after upgrading to 66.0.1-1.fc29.  However, after changing a couple of settings:

- History → Clear history when Firefox closes (checked) → Settings (changed some options)
- Address bar (when using address bar suggest) → uncheck "bookmarks"

The issue seems to have resolved itself.

Comment 2 Dimitris 2019-03-28 00:17:05 UTC
Spoke too soon, it's starting to happen again.  Not as pronounced as before; about half the time URL bar searches work without delay, but I am beginning to see this "multiple key press" behavior more and more.

Comment 3 Dimitris 2019-03-30 01:21:31 UTC
Did a little more experimenting today:

- This seems to be some kind of race condition between the *first* keypress in the address bar and the creation of the matching history/searches dropdown list.  I can "work around" it if I either delete all but one of the incorrectly-echoed-multiple-times first letter, or if I simply press space before typing the "real" text I want to find/match in the history dropdown.

- I can only reproduce this on firefox-wayland.  Running X11 firefox the address bar/keyboard interaction is normal.

- Running the browser in safe mode doesn't change anything, the bug persists there when running firefox-wayland.

- This is all under a Wayland desktop.

Comment 4 Dimitris 2019-03-31 23:48:13 UTC
Booted and running without an external keyboard for the first time with the 66 series, and I can't reproduce this.  So does seem relevant.

Comment 5 Martin Stransky 2019-04-01 07:43:22 UTC
Dimitris, do you run sway compositor? The is for sway, not gnome-shell.

Comment 6 Dimitris 2019-04-01 15:42:00 UTC
Hi, I'm running gnome-shell.

BTW after suspending and docking the laptop (external USB keyboard connected to the dock), once I resume the same session of firefox-wayland is now back to multi-registering the first keypress in the address bar.  The dock also connects an external, second monitor.

Comment 7 Dimitris 2019-04-01 15:49:03 UTC
OK, I did a little more testing with the same running firefox-wayland process and the problem seems to actually correlate with the Firefox window displaying on the external, secondary display.  When the window is on the laptop panel (primary on the gnome-wayland session), the address bar seems to behave normally.

Comment 8 Dimitris 2019-04-01 18:03:02 UTC
A couple more data points:

- The problem seems associated with the window being on the external display, but independent of which display is set as primary in Gnome Shell.

- The problem follows the specific window.  For example if I have a regular window open on the external display and open a separate private window, moving that new private window shows the correlation to external display even if the original one stays where it was.

Comment 9 Dimitris 2019-04-02 18:54:26 UTC
No change with 66.0.2-1.fc29

Comment 10 Christian Stadelmann 2019-05-14 20:41:21 UTC
Also present with Fedora 30 (gnome-shell/wayland) on my primary and only monitor. Not using an external monitor.

Comment 11 Dimitris 2019-05-25 18:00:32 UTC
Still present through updates, now to 67.0-4.fc29 which included a hopeful-sounding Wayland rendering fix.

Comment 12 Dimitris 2019-07-15 02:48:49 UTC
As of 68.0-4.fc30, running in a wayland session and the firefox-wayland launcher, I no longer see this issue.  I also notice that this version has picked up my global desktop style (dark). Leaving open for Christian to confirm.

Comment 13 Christian Stadelmann 2019-07-17 21:54:18 UTC
I'm still seeing this issue with firefox 68.0-4.fc30. Installing some gnome-shell/mutter patches from temporarily got this issue go away but now I'm still seeing it.

Comment 14 Martin Stransky 2019-07-23 13:31:33 UTC
*** Bug 1693911 has been marked as a duplicate of this bug. ***

Comment 15 Martin Stransky 2019-07-23 13:33:05 UTC
I see that in other applications too, like xchat/terminal. Not exclusively Firefox Wayland issue.

Comment 16 Christian Stadelmann 2019-07-27 15:53:56 UTC
(In reply to Martin Stransky from comment #15)
> I see that in other applications too, like xchat/terminal. Not exclusively
> Firefox Wayland issue.

Hm, I don't. This issue has only been present in Firefox for me.

Comment 17 Martin Stransky 2019-07-29 05:52:02 UTC
Is there any change you can try wl-clipboard tools? ( If you install it you can run wl-paste on terminal and it shows you the clipboard content and you can easily check if there's a problem with clipboard source or destination. For instance I regularly can't paste to gnome-terminal.

Comment 18 Dimitris 2019-09-14 07:15:02 UTC
This has been fixed for me starting with v68 and continuing with v69.

Comment 19 Christian Stadelmann 2020-03-02 12:02:15 UTC
(In reply to Dimitris from comment #18)
> This has been fixed for me starting with v68 and continuing with v69.

I have not seen this issue in a long time either, so I couldn't reproduce it any more.

Note You need to log in before you can comment on or make changes to this bug.