Open Bug 1907708 Opened 1 year ago Updated 1 year ago

Firefox no long scrolls with middle-mouse wheel unless window is raised to top level

Categories

(Core :: Widget: Gtk, defect, P3)

Product:
Core
Component:
Widget: Gtk
Type:
defect

Tracking

()

Status:
UNCONFIRMED

People

(Reporter: drankinatty, Unassigned)

Details

Attachments

(2 files)

Xev event trace attached to Firefox window (2 mouse-overs, 1 click to raise)
33.92 KB, application/octet-stream
Details
about:support information
44.32 KB, text/plain
Details

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/115.0

Steps to reproduce:

Firefox 115.11.0esr
openSUSE Tumbleweed. I use KDE with focus-follows-mouse (sloppy focus). This is the same preference in many Linux desktops. Many times I have other windows open on top of the browser with only part of the browser window shown. I have always been able to simply move focus to the Firefox window and middle-mouse-scroll to where ever in the page I'm interested in getting information from. This has always worked fine.

Actual results:

Recently, when I move the mouse over Firefox, the titlebar shows the Firefox window has focus, but Firefox will NOT scroll page content up/down in response to the middle mouse wheel UNTIL I click to raise the Firefox window above all others. This is horribly frustrating.

Expected results:

When the Firefox window receives focus, all input to the focused window should be interpreted by that window. When I move the mouse over the Firefox window, the middle-mouse-wheel should scroll the contents. This stopped happening in the past couple of weeks.

Current build info:

Application Basics
------------------

Name: Firefox
Version: 115.11.0esr
Build ID: 20240506144012
Distribution ID: openSUSE
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/115.0
OS: Linux 6.9.7-1-default #1 SMP PREEMPT_DYNAMIC Fri Jun 28 05:50:47 UTC 2024 (a5efffa)
OS Theme: Material-Black-Blueberry / Adwaita
Multiprocess Windows: 1/1
Fission Windows: 1/1 Enabled by default
Remote Processes: 19
Enterprise Policies: Inactive
Google Location Service Key: Missing
Google Safebrowsing Key: Found
Mozilla Location Service Key: Found
Safe Mode: false
Memory Size (RAM): 7.7 GB
Disk Space Available: 832 GB

The Bugbug bot thinks this bug should belong to the 'Core::Performance' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → Performance
Product: Firefox → Core
Version: other → unspecified

Diagnosing further, this only effect Firefox (now 128.0esr) and Thunderbird. I attached xev to the firefox window id and captured the list of window events for two occurrences of moving the mouse over the window and a scroll up on the mouse-wheel and scroll down on the mouse-wheel and leave again. After repeating that process twice, I clicked to raise the window and the mouse-wheel scroll then works.

Each time the mouse enters the firefox window, the EnterNotify event is triggered, but amazingly with focus NO, state 2048 (for scroll UP) and focus NO, state 4096 (for scroll DOWN).

It is not until the window is clicked that a focus YES, state 256 is seen.

UUGH....

This may be the mother-of-all-regressions somewhere in the code or build process. Researching the issue I have uncovered Scrolling inactive windows in KDE/KWin with mouse wheel which points back to an earlier bug here: Mousewheel action over Firefox doesn't work if Firefox window is not active

To top it all off, my firefox and thunderbird come from the openSUSE:mozilla/ software repository.

Now the crux of the issue is I have used firefox and thunderbird since the very early 1.x days, and for the more recent several years from the openSUSE:mozilla repository. This has not been a problem until the past few weeks. (I would notice, I have made extensive use of the focus-follows-mouse focus model for the past 20 years, and use it daily with firefox/thunderbird)

So this problem has raised its head again, now likely with a Gtk4 variant that no longer respects whatever fix was made earlier. Let me know what other info I can provide and I'm happy to get it. I'll try the export GDK_CORE_DEVICE_EVENTS=1 mentioned in the Arch forum post, but apparently it has side-effects that may cause other issues.

This issue is limited to kwin on Tumbleweed desktop on openSUSE. I have confirmed export GDK_CORE_DEVICE_EVENTS=1 does indeed provide a work-around to the issue. I don't know why this happens, but at least where the problem is is understood.

I'll leave this open for review and it can be closed if warranted. However it would be nice to find an actual solution.

This bug was moved into the Performance component.

:drankinatty, could you make sure the following information is on this bug?

  • For slowness or high CPU usage, capture a profile with http://profiler.firefox.com/, upload it and share the link here.
  • For memory usage issues, capture a memory dump from about:memory and attach it to this bug.
  • Troubleshooting information: Go to about:support, click "Copy raw data to clipboard", paste it into a file, save it, and attach the file here.

If the requested information is already in the bug, please confirm it is recent.

Thank you.

Flags: needinfo?(drankinatty)
**about:support** The requested information is: ```none

about:support

The requested information is provided in the attachment - that bugzilla created automagically -- nice trick.

NOTE:

The GDK_CORE_DEVICE_EVENTS=1 environment variable was MANUALLY SET to run firefox and have the focus-follows-mouse and mouse-wheel-scroll work when the firefox window was not at the top-level. E.g., firefox was started with:

$ GDK_CORE_DEVICE_EVENTS=1 firefox-esr &

If firefox is started without GDK_CORE_DEVICE_EVENTS=1 this bug occurs with kwin.

(In reply to David Rankin from comment #6)

about:support

The requested information is:

For some reason clicking the Clear the needino didn't work, trying again here.

(In reply to BugBot [:suhaib / :marco/ :calixte] from comment #5)

This bug was moved into the Performance component.

:drankinatty, could you make sure the following information is on this bug?

  • For slowness or high CPU usage, capture a profile with http://profiler.firefox.com/, upload it and share the link here.
  • For memory usage issues, capture a memory dump from about:memory and attach it to this bug.
  • Troubleshooting information: Go to about:support, click "Copy raw data to clipboard", paste it into a file, save it, and attach the file here.

If the requested information is already in the bug, please confirm it is recent.

Thank you.

Bugzilla created the attachment of the about:support information. I've added a couple of comments and was unable to clear the needinfo. I'll try again here in direct reply to the comment requesting it. See the new attachment containing the current about:support info and NOTE the GDK_CORE_DEVICE_EVENTS=1 environment variable shown in the about:support was manually set when launching firefox this time (see comment 7)

Flags: needinfo?(drankinatty)

Moving to the right component.

Component: Performance → Widget: Gtk

I've been troubleshooting this further. It seems to affect kwin. This laptop has 3 mice listed by xinput. They are:

⎡ Virtual core pointer                          id=2    [master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer                id=4    [slave  pointer  (2)]
⎜   ↳ Microsoft Microsoft 3-Button Mouse with IntelliEye(TM)    id=9    [slave  pointer  (2)]
⎜   ↳ PS/2 Generic Mouse                        id=11   [slave  pointer  (2)]
⎜   ↳ SynPS/2 Synaptics TouchPad                id=12   [slave  pointer  (2)]
⎣ Virtual core keyboard                         id=3    [master keyboard (2)]
    ↳ Virtual core XTEST keyboard               id=5    [slave  keyboard (3)]
    ↳ Power Button                              id=6    [slave  keyboard (3)]
    ↳ Video Bus                                 id=7    [slave  keyboard (3)]
    ↳ Sleep Button                              id=8    [slave  keyboard (3)]
    ↳ AT Translated Set 2 keyboard              id=10   [slave  keyboard (3)]
    ↳ HP WMI hotkeys                            id=13   [slave  keyboard (3)]

The Microsoft 3-Button Mouse is the one affected by this problem. For whatever reason, the xinput event for mousewheel scroll is not being seen by firefox or thunderbird. The "PS/2 Generic Mouse" has no buttons, it's just one of those stupid red eraser nubs in the middle of the keyboard you have to re-learn to type around. The "SynPS/2 Synaptics TouchPad" is the touchpad for the laptop and it has actual buttons and the 2-finger scroll WORKS with firefox and thunderbird with focus-follows-mouse. (It is using the synaptics driver -- so this problem looks limited to xinput/libinput).

The xinput details between the "Microsoft 3-Button Mouse with IntelliEye(TM)" and the "SynPS/2 Synaptics TouchPad" are:

$ xinput --list-props "Microsoft Microsoft 3-Button Mouse with IntelliEye(TM)"
Device 'Microsoft Microsoft 3-Button Mouse with IntelliEye(TM)':
        Device Enabled (153):   1
        Coordinate Transformation Matrix (155): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
        libinput Natural Scrolling Enabled (283):       0
        libinput Natural Scrolling Enabled Default (284):       0
        libinput Scroll Methods Available (285):        0, 0, 1
        libinput Scroll Method Enabled (286):   0, 0, 0
        libinput Scroll Method Enabled Default (287):   0, 0, 0
        libinput Button Scrolling Button (288): 2
        libinput Button Scrolling Button Default (289): 2
        libinput Button Scrolling Button Lock Enabled (290):    0
        libinput Button Scrolling Button Lock Enabled Default (291):    0
        libinput Middle Emulation Enabled (292):        0
        libinput Middle Emulation Enabled Default (293):        0
        libinput Rotation Angle (266):  0.000000
        libinput Rotation Angle Default (267):  0.000000
        libinput Accel Speed (294):     0.000000
        libinput Accel Speed Default (295):     0.000000
        libinput Accel Profiles Available (296):        1, 1, 1
        libinput Accel Profile Enabled (297):   1, 0, 0
        libinput Accel Profile Enabled Default (298):   1, 0, 0
        libinput Accel Custom Fallback Points (299):    <no items>
        libinput Accel Custom Fallback Step (300):      0.000000
        libinput Accel Custom Motion Points (301):      <no items>
        libinput Accel Custom Motion Step (302):        0.000000
        libinput Accel Custom Scroll Points (303):      <no items>
        libinput Accel Custom Scroll Step (304):        0.000000
        libinput Left Handed Enabled (305):     0
        libinput Left Handed Enabled Default (306):     0
        libinput Send Events Modes Available (268):     1, 0
        libinput Send Events Mode Enabled (269):        0, 0
        libinput Send Events Mode Enabled Default (270):        0, 0
        Device Node (271):      "/dev/input/event4"
        Device Product ID (272):        1118, 64
        libinput Drag Lock Buttons (307):       <no items>
        libinput Horizontal Scroll Enabled (308):       1
        libinput Scrolling Pixel Distance (309):        15
        libinput Scrolling Pixel Distance Default (310):        15
        libinput High Resolution Wheel Scroll Enabled (311):    1

and

$ xinput --list-props "SynPS/2 Synaptics TouchPad"
Device 'SynPS/2 Synaptics TouchPad':
        Device Enabled (153):   1
        Coordinate Transformation Matrix (155): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
        Device Accel Profile (279):     1
        Device Accel Constant Deceleration (280):       2.500000
        Device Accel Adaptive Deceleration (281):       1.000000
        Device Accel Velocity Scaling (282):    12.500000
        Synaptics Edges (312):  1767, 5397, 1649, 4615
        Synaptics Finger (313): 25, 30, 0
        Synaptics Tap Time (314):       180
        Synaptics Tap Move (315):       239
        Synaptics Tap Durations (316):  180, 180, 100
        Synaptics ClickPad (317):       0
        Synaptics Middle Button Timeout (318):  75
        Synaptics Two-Finger Pressure (319):    282
        Synaptics Two-Finger Width (320):       7
        Synaptics Scrolling Distance (321):     108, 108
        Synaptics Edge Scrolling (322): 0, 0, 0
        Synaptics Two-Finger Scrolling (323):   1, 0
        Synaptics Move Speed (324):     1.000000, 1.750000, 0.036704, 0.000000
        Synaptics Off (325):    0
        Synaptics Locked Drags (326):   0
        Synaptics Locked Drags Timeout (327):   5000
        Synaptics Tap Action (328):     0, 0, 0, 0, 1, 3, 2
        Synaptics Click Action (329):   1, 1, 1
        Synaptics Circular Scrolling (330):     0
        Synaptics Circular Scrolling Distance (331):    0.100000
        Synaptics Circular Scrolling Trigger (332):     0
        Synaptics Circular Pad (333):   0
        Synaptics Palm Detection (334): 0
        Synaptics Palm Dimensions (335):        10, 200
        Synaptics Coasting Speed (336): 20.000000, 50.000000
        Synaptics Pressure Motion (337):        30, 160
        Synaptics Pressure Motion Factor (338): 1.000000, 1.000000
        Synaptics Grab Event Device (339):      0
        Synaptics Gestures (340):       1
        Synaptics Capabilities (341):   1, 1, 1, 1, 1, 1, 1
        Synaptics Pad Resolution (342): 81, 40
        Synaptics Area (343):   0, 0, 0, 0
        Synaptics Noise Cancellation (344):     27, 27
        Device Product ID (272):        2, 7
        Device Node (271):      "/dev/input/event3"

I'm no expert in reading the information, but it all looks okay on this end. Maybe some eagle-eyed mozdev can spot something I'm missing. This seems like a small issue, but after using focus-follows-mouse and firefox and thunderbird for nearly 20 years, not being able to scroll the FF or TB is immediately noticeable and quite frustrating to work-around. It's like being on Windows.

Let me know if you can think of any additional information that may help identify where this problem is and I'll happily provide. Currently I'm just launching FF and TB by wrapper scripts that sets the GDK_CORE_DEVICE_EVENTS=1 environment variable as a work-around for the Microsoft 3-Button Mouse. It works, e.g.

#!/bin/sh

GDK_CORE_DEVICE_EVENTS=1 firefox-esr &

I'm a bit confused here. Is that a bug in Firefox itself or in the environment? Did it worked in any Firefox version before? Is that a regression?
Thanks.

Flags: needinfo?(drankinatty)
Priority: -- → P3

Sorry for being unclear. This appears to be a change that has occurred in the updates from openSUSE Leap 15.4 and openSUSE Tumbleweed. What component it is in or whether it is a regression, I'm not sure.

In Leap 15.4 FF 115, focus-follows-mouse and middle-mouse-scroll works with FF 115.

After fresh install of openSUSE Tumbleweed with FF 115, focus-follows-mouse is broken and exhibits behavior described in this bug.

In both cases, the install is from the http://download.opensuse.org/repositories/mozilla/ repository. While this bug was pending, the mozilla repo updated firefox-esr to ver. 128 and the bug persists on Tumbleweed. As 15.4 is now end-of-life, the mozilla repository for that release is no longer published.

Flags: needinfo?(drankinatty)

Can you please try Mozilla binaries with a new profile?
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Testing_Mozilla_binaries
Thanks.

Flags: needinfo?(drankinatty)

Yes, let me grab the updated binary from the ftp site. I can install it in parallel with the openSUSE version since it installs to /opt. This problem is quite frustrating. I've used Firefox and Thunderbird for 20 years on Linux and never before had an issue with middle-mouse scroll of any window not at the toplevel.

I've noticed other oddness on Tumbleweed, that tries to provide current upstream packages (verses Leap, or the other traditional release-model that stuck for the most part to versions of software provided with the release). Of relevance here is also left-click issues where some Gtk apps require 2 mouse-clicks to actually press the first button when opening an app. Almost like Gtk input handling has a generic problem with focus before actually interpreting mouse input events. That is generically what it looks like is happening here. Only here with mouse-over and middle-mouse-scroll, Firefox/Thunderbird never seen the focus event until they are clicked on. Where that goes wrong in the X, libinput, desktop, toolkit, app hierarchy is hard to tell.

Will report back after installing the binary.

Flags: needinfo?(drankinatty)

Damn! You nailed it!

Grabbed 128.2.0esr binary and installed it to /opt. Tested and it scrolls fine with middle-mouse when it is not the top-level window. So the openSUSE developers packaging for the "mozilla" package repository are doing something that breaks middle-mouse scrolling in both Firefox and Thunderbird.

Do you have an open line to the developers in openSUSE to communicate with them about the issue? In my research of this bug before filing, there were earlier bugs listed here that discussed issues with packages from that repository. Perhaps a regression in how they are building? I have a Leap 15.4 install with Firefox from the mozilla repo -- no problems. So the issue looks like it is due to building against the current packages that Tumbleweed uses.

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

Attachment

General

Creator:
Created:
Updated:
Size: