Focus-Follows-Mouse lost mouse-wheel-scroll unless Gtk app is top-level in SUSE KDE3 - Seen in TDE?
TDE devs,
Here is an odd bit of behavior with a new KDE3 install on openSUSE Tumbleweed I'm trying to chase down and wonder if this has been seen on TDE yet. The basic problem is with focus-follows-mouse set and no longer being able to scroll Firefox or Thunderbird windows with the mouse-wheel UNLESS the window is click and made top-level. (kinda defeats the purpose of focus-follows-mouse...)
There is no question that the window receives focus, everything else works, titlebar indicates focus, you can 'tab' between widgets in FF or TB, but the mouse scroll does not work.
As a work-around you can set the environment variable GDK_CORE_DEVICE_EVENTS=1 when starting either and then the focus-follows-mouse works normally.
I've opened a bug:
Firefox Bug - no middle-mouse scroll on focused window not raised to top https://bugzilla.mozilla.org/show_bug.cgi?id=1907708
only to find this is not a new issue:
Scrolling inactive windows in KDE/KWin with mouse wheel https://bbs.archlinux.org/viewtopic.php?id=239918
Mousewheel action over Firefox doesn't work if Firefox window is not active https://bugzilla.mozilla.org/show_bug.cgi?id=1359226
and to find this is likely related to the new KDE3 builds at openSUSE. I have a Leap-15.4 install where KDE3 hasn't been updated since Sept. 2023 (it was perfect -- why tempt something like this ....) So it may be related to library version changes in the past 6 months or kernel differences between 5.4 and 6.9 or it could be due to a cockup in the build system.
Long story short I'm looking for more data points to help narrow down where/what is causing this. Since this may be a Linux 6.9 or recent library issue, I thought I would check if TDE has seen anything like this?
Also, a possible related issue has to do with the Run Command dialog (Alt+F2) which I can summarize in a test case:
Test Case:
1. Alt + F2 2. type kmenuedit (tmenuedit on TDE IIRC) 3. return (to run it) 4. close kmenuedit 5. Alt + F2 6. type kmenuedit again
As you type the 'k' ('t' on TDE?) you will see the icon displayed change to the kmenuedit icon showing at least the search-as-you-type part has identified the prior kmenuedit command -- but -- the list-box does not open. You have to manually click the list-box to see the previous kmenuedit command.
I don't know if this is related, but I thought I would add that scenario as well. If you can't currently reproduce any of this -- good! But keep this in mind if it should crop up in the future.
David C. Rankin via tde-devels wrote:
Long story short I'm looking for more data points to help narrow down where/what is causing this. Since this may be a Linux 6.9 or recent library issue, I thought I would check if TDE has seen anything like this?
you can easily install older kernels and keep the rest the same, so that you exclude the least probable cause. (not sure if easily is so easy in SuSE though)
On 7/20/24 12:26 AM, deloptes via tde-devels wrote:
David C. Rankin via tde-devels wrote:
Long story short I'm looking for more data points to help narrow down where/what is causing this. Since this may be a Linux 6.9 or recent library issue, I thought I would check if TDE has seen anything like this?
you can easily install older kernels and keep the rest the same, so that you exclude the least probable cause. (not sure if easily is so easy in SuSE though)
Thank you for the reply!
I have another install on the 5.14 kernel (Leap 15.4) and all is fine there. This is definitely an issue related to kwin. fluxbox on this same system with the 6.9 kernel does not show the issue.
I'm still working to narrow this issue down. xinput hasn't disclosed any difference in how the mouse is seen, so that was a dead-end.
In the interim, I've just added a kmenu entry pointing to a wrapper that sets the environment variable work-around, e.g.
#!/bin/sh
GDK_CORE_DEVICE_EVENTS=1 firefox-esr &
This also could be an issue in Gtk4 and how it doesn't play nice with the mouse events sent by kde3/kwin. Hard to tell where the exact issue is. I'll keep you posted as I find more out.
We got the kmix issue fixed - the new ALSA must be built with the C11 standard options (e.g. --std=c11).
Only other strangeness I see so far with kde3 built on the bleeding edge libs is for some reason Alt-F2 (Run Command) doesn't automatically drop down the combo-box when you start typing a command you have used before. (Alt-DownArrow is required) No guess here either unless there is another missed --std=c11 on libinput or the like -- I'll also report back if I find anything here that may need to be addressed in the TDE build.
-
David C. Rankin -
deloptes