Chromium repeat the previous mouse wheel actions from other windows

la1den · 2024-09-22 02:05:56

In the GNOME environment, Chromium and VSCode (and possibly other Electron-based applications) repeat the previous mouse wheel actions from other windows. When I use the left Windows key to tile the Chromium window and switch to another window, scrolling up (the window scrolls up), then return to the Chromium window and scroll down, the window still scrolls up, repeating the previous scroll action.

Is this a bug or caused by my configuration? Has anyone else encountered this issue?

seth · 2024-09-22 07:02:18

There was some thread about input transfer on gome and I'm pretty sure it was because of xwayland clients (but can't find the thread rn)
Chromium also had a bug where it was accidentally™ running on xwayland, try to force a native client: https://wiki.archlinux.org/title/Chromi … nd_support

la1den · 2024-09-22 10:40:05

I am using a combination of X11 and Nvidia, but I had previously installed the xorg-xwayland package. Could it be that a configuration change occurred during a system update, or is this simply a Chromium bug?

seth · 2024-09-22 13:10:56

You get this on an X11 session???

Start an openbox (or icewm, any basic WM will do) session and check whether the same behavior exists there.
If yes, try to

export GDK_CORE_DEVICE_EVENTS=1

to the entire session - how do you log in? GDM? Does that run on X11 or (by default) on wayland?

la1den · 2024-09-22 13:56:12

Yes. I previously migrated from KDE6 to GNOME due to poor NVIDIA performance. I'm using GDM. This bug seems to only trigger when using the tiling window feature in GNOME while switching windows. I tested it in KDE, and it's working fine there. Do other desktop environments have tiling window functionality?

seth · 2024-09-22 14:25:21

Do other desktop environments have tiling window functionality?

i3? sway? awesome?
https://wiki.archlinux.org/title/Window … w_managers

Gnome defaults to wayland

loginctl session-status

la1den · 2024-09-23 03:32:46

I tried entering the following command, and the output was as follows. I think I should be using X11.

$ loginctl session-status | grep Type                                                                                                                                            
   Type: x11

I see that the default window manager for GNOME is Mutter, which is classified as a Stacking window manager on the wiki.
Perhaps there's no need to choose Tiling window managers for testing.

I think my previous description may have been incorrect.
What I meant to say is that when using GNOME's window list to tile windows, there's a duplication issue when switching between windows in this interface.
When I tested the window list on Plasma, it worked normally.

Additionally, only scrolling in other windows can affect Chromium and VSCode, but not the other way around.
Moreover, Chromium and VSCode seem to affect each other.

Last edited by la1den (2024-09-23 03:33:36)

seth · 2024-09-23 07:13:39

Perhaps there's no need to choose Tiling window managers for testing.

Nope, the details on the WM don't matter as long as you're not starting gnome, but

What I meant to say is that when using GNOME's window list to tile windows, there's a duplication issue when switching between windows in this interface.

so the problem is exclusive to this UI element - have you tried to globally "export GDK_CORE_DEVICE_EVENTS=1"?

The problem is probably some event replay or by the WM and the events timestamps, https://tronche.com/gui/x/xlib/input/po … bbing.html
Gnome always had issues w/ wheel replays, GDK_CORE_DEVICE_EVENTS used to prevent those but that's from GTK3, so idk whether that still helps here.

la1den · 2024-09-23 09:08:01

have you tried to globally "export GDK_CORE_DEVICE_EVENTS=1"

I added GDK_CORE_DEVICE_EVENTS=1 to /etc/environment and tested with GNOME and Plasma. Plasma works fine, but GNOME still has the same issue.
I am not very familiar with system programming and am not sure if this is the correct way to do it.

seth · 2024-09-23 13:49:55

What's the exact intrface you use to switch the window arrangement/focus?
It doesn't happen if you just alt+tab switch around?
Is the effect singular or permanent? Can you break it (ie. prevent the duplication) eg. by switching the focus around? How?

Ultimately you'll have to file a gnome bug, idk. enough about the DE, but my gut feeling is that this is down to the _NET_WM_USER_TIME property/handling
If you compare it between chromium and an unaffected client, are the values vastly different (they should update anytime you interact w/ them)

xprop _NET_WM_USER_TIME # then click the window of interest

la1den · 2024-09-24 02:58:26

What's the exact intrface you use to switch the window arrangement/focus?

In GNOME, I use the Win key to display the windows list, while in Plasma, I use Ctrl+F9, which is a shortcut for a similar function to show the windows list.

It doesn't happen if you just alt+tab switch around?

I rarely trigger it, but there's still a chance. After trying it a dozen times, it only triggers about once.
It seems that to trigger it, you need to use Alt+Tab to switch windows immediately after scrolling; only then is there a chance it will trigger on the next scroll.

Is the effect singular or permanent? Can you break it

I feel it should be singular. After quickly switching windows and waiting for half a minute before scrolling, I tried it a few times and it worked normally. However, if I only wait about 10 seconds, it will still repeat the last scroll action from another window.

If you compare it between chromium and an unaffected client, are the values vastly different (they should update anytime you interact w/ them)

Chromium and VSCode output the following:

_NET_WM_USER_TIME(CARDINAL) = 4235136 #chromium
_NET_WM_USER_TIME(CARDINAL) = 4237995 #vscode

The output from other windows is as follows:

_NET_WM_USER_TIME:  not found.

Ultimately you'll have to file a gnome bug, idk.

I haven't tried submitting a bug to GNOME yet; I'll look into how to do it.

seth · 2024-09-24 07:01:16

_NET_WM_USER_TIME: not found.

Not every client supports that protocol, you'll have to find an unaffected one and compare that (immediately after interacting with each) for meaningful data.
For the above results, their interaction timestamp is ~3s apart and the X11 server would have been running for ~70 minutes at the time.

Do you maybe have to unminimize the window to trigger this?

la1den · 2024-09-24 08:41:43

Not every client supports that protocol, you'll have to find an unaffected one and compare that (immediately after interacting with each) for meaningful data.

I tested more than a dozen applications, and only one application (fluent-reader) has the _NET_WM_USER_TIME value. Then I tested it and found that this application is also affected by Chromium.
Furthermore, if an application (Chromium) is influenced by other applications (like VSCode or fluent-reader), it cannot in turn affect the applications that influenced it.

I can't find any other applications that have the _NET_WM_USER_TIME value but are not affected.

Do you maybe have to unminimize the window to trigger this?

I tested by placing the two windows side by side and switching between them.

Last edited by la1den (2024-09-24 08:52:35)

la1den · 2024-09-24 08:47:18

Also, when the affected application scrolls next time, the distance and direction of the scroll are the total of the previous window's scrolling. For example, if I scroll up two circles and then down one circle, the affected application will scroll up one circle next time.

seth · 2024-09-24 13:54:00

I can't find any other applications that have the _NET_WM_USER_TIME value but are not affected.

gtk3-demo ?
But sounds like a general bug in mutter's handling of the property rather than chromium or any specific client.
Was this also a problem w/ gnome 46?

la1den · 2024-09-25 03:41:26

gtk3-demo ?

What does this mean?

Was this also a problem w/ gnome 46?

I'm not quite sure. However, when I test Firefox, settings, and calculator apps under Plasma, they all have a _NET_WM_USER property, but in GNOME, they don't.

The version of GNOME I'm using now is 47.

seth · 2024-09-25 07:22:48

What does this mean?

https://archlinux.org/packages/extra/x86_64/gtk3-demos/
It just demonstrates the toolkit features and should™ set _NET_WM_USER_TIME what makes it a usable testcase.

I'm not quite sure. However, when I test Firefox, settings, and calculator apps under Plasma, they all have a _NET_WM_USER property, but in GNOME, they don't.

When you grepped the session status, was that on plasma or gnome?
The situation you describe sound like you're on wayland and chromium runs on xwayland, https://wiki.archlinux.org/title/Chromi … er_Wayland (ignore the symptom)

la1den · 2024-09-25 13:00:21

https://archlinux.org/packages/extra/x86_64/gtk3-demos/
It just demonstrates the toolkit features and should™ set _NET_WM_USER_TIME what makes it a usable testcase.

However, I did not install gtk3-demos.

When you grepped the session status, was that on plasma or gnome?

I tried it on both platforms, and they are both X11.

This issue has been quite a headache for me, so I can only return to Plasma for refuge. If I want to report it to GNOME, should I go to the official forum? (I'm a bit busy right now, so it might take some time.) Should I mark this forum as 'solved'? The progress on this issue seems to have stalled for now.

seth · 2024-09-25 14:47:07

The idea would have been to install gtk3-demos as testcase …

f I want to report it to GNOME, should I go to the official forum?

https://gitlab.gnome.org/GNOME/mutter/-/issues

Should I mark this forum as 'solved'?

No, it's not at all solved. We've at best a vague idea what's driving the issue.

la1den · 2024-09-25 15:15:16

https://gitlab.gnome.org/GNOME/mutter/-/issues/3690

I think I don't need to raise a new issue. The problem described in this post is basically the same as mine.

Last edited by la1den (2024-09-25 15:23:55)

seth · 2024-09-25 15:58:08

Does https://extensions.gnome.org/extension/ … orkaround/ also address your problem (there seems to be a second issue w/ mutter where the input goes stale on a window)

some dev on the 401 bug wrote:

Mutter is not involved in delivering input events to clients on X11

This is more or less the problem. It seems mutter only passively moitors events via XI2 and doesn't control the input at all, but happily switches the focus around.
The consequence is that one window gets to see the button press and the next window the release.
The above extension simply generates an idempotent mouse move what will likely let the windows know that the pointer has entered/left them.

I assume you cannot reproduce this when scrolling, switching the focus, moving the mouse a bit and then scrolling the wrong direction?

la1den · 2024-09-26 03:38:21

This extension currently doesn't support GNOME 47 yet. I'll give it a try once it's supported. I think it should be able to solve my problem.

I assume you cannot reproduce this when scrolling, switching the focus, moving the mouse a bit and then scrolling the wrong direction?

I first scroll in a Chromium window, then switch to the VSCode window using the window list (with the mouse already over the VSCode window), and then move the mouse back to the Chromium window and back again. This doesn't cause any jumpy scrolling.(I am currently in a state where the above extension is not installed.)

So both Chromium and VSCode detected my mouse press, but only Chromium detected the mouse release. When I switch focus using the window list, VSCode doesn't realize that I have already finished the operation in Chromium. As a result, my next action triggers the release, causing a jump. Is that correct?

Last edited by la1den (2024-09-26 04:01:30)

seth · 2024-09-26 06:59:02

You can "xev -id <window id> -event mouse" on either window to record what they're actually seeing, when.
But you should™ not see the same event being delivered to two windows, it's more that a pair (mouse down/up) gets spread between them.

Do the windows overlap and you alter the z-stack order (which one's on top) underneath a fixed cursor position mouse when this happens?
Either way, this is really a behavior very peculiar to mutter and likely its derivates. I can see how you come to the conclusion that it's much easier to not intercept the input but just passively listen to it as second client, but that quickly causes problems if you start to mess around the window stack in responds to those events and is not like any WM did (in part because XI2 is relatively new, by X11 standards - only a decade or so)

la1den · 2024-09-26 10:12:07

You can "xev -id <window id> -event mouse" on either window to record what they're actually seeing, when.
But you should™ not see the same event being delivered to two windows, it's more that a pair (mouse down/up) gets spread between them.

I tried, and when the scroll wheel moves in the window I’m monitoring, it does receive a pair of events. However, under Chromium, the scroll wheel events are not received, whereas in VSCode, it does receive a pair of events.

Do the windows overlap and you alter the z-stack order (which one's on top) underneath a fixed cursor position mouse when this happens?

What is the meaning of 'a fixed cursor position mouse'?

I feel like this bug is a bit beyond my abilities, so I'll wait until the plugin supports GNOME 47 before trying again. If the issue gets resolved, I'll come back and mark the title as 'solved'.

seth · 2024-09-26 13:32:21

What is the meaning of 'a fixed cursor position mouse'?

You're not moving the cursor (into or out of the window or at all) but it enters a different window because alt+tab changes the stack order (new window on top)

I feel like this bug is a bit beyond my abilities, so I'll wait until the plugin supports GNOME 47 before trying again. If the issue gets resolved

This is currently just to collect some data on the condition for other users. Regardless of what the gnome devs say, this is very much a mutter "bug" (or rather inherent to its approach) and since they're refusing to address it and rather would like to wait for the world to bend around them, this will likely remain a bug w/ mutter that you can work around with that simple extension or alternatively
* use gnome on wayland
* don't use gnome (or its derivates, the problem is the WM, not the desktop shell)

Arch Linux

#1 2024-09-22 02:05:56

Chromium repeat the previous mouse wheel actions from other windows

#2 2024-09-22 07:02:18

Re: Chromium repeat the previous mouse wheel actions from other windows

#3 2024-09-22 10:40:05

Re: Chromium repeat the previous mouse wheel actions from other windows

#4 2024-09-22 13:10:56

Re: Chromium repeat the previous mouse wheel actions from other windows

#5 2024-09-22 13:56:12

Re: Chromium repeat the previous mouse wheel actions from other windows

#6 2024-09-22 14:25:21

Re: Chromium repeat the previous mouse wheel actions from other windows

#7 2024-09-23 03:32:46

Re: Chromium repeat the previous mouse wheel actions from other windows

#8 2024-09-23 07:13:39

Re: Chromium repeat the previous mouse wheel actions from other windows

#9 2024-09-23 09:08:01

Re: Chromium repeat the previous mouse wheel actions from other windows

#10 2024-09-23 13:49:55

Re: Chromium repeat the previous mouse wheel actions from other windows

#11 2024-09-24 02:58:26

Re: Chromium repeat the previous mouse wheel actions from other windows

#12 2024-09-24 07:01:16

Re: Chromium repeat the previous mouse wheel actions from other windows

#13 2024-09-24 08:41:43

Re: Chromium repeat the previous mouse wheel actions from other windows

#14 2024-09-24 08:47:18

Re: Chromium repeat the previous mouse wheel actions from other windows

#15 2024-09-24 13:54:00

Re: Chromium repeat the previous mouse wheel actions from other windows

#16 2024-09-25 03:41:26

Re: Chromium repeat the previous mouse wheel actions from other windows

#17 2024-09-25 07:22:48

Re: Chromium repeat the previous mouse wheel actions from other windows

#18 2024-09-25 13:00:21

Re: Chromium repeat the previous mouse wheel actions from other windows

#19 2024-09-25 14:47:07

Re: Chromium repeat the previous mouse wheel actions from other windows

#20 2024-09-25 15:15:16

Re: Chromium repeat the previous mouse wheel actions from other windows

#21 2024-09-25 15:58:08

Re: Chromium repeat the previous mouse wheel actions from other windows

#22 2024-09-26 03:38:21

Re: Chromium repeat the previous mouse wheel actions from other windows

#23 2024-09-26 06:59:02

Re: Chromium repeat the previous mouse wheel actions from other windows

#24 2024-09-26 10:12:07

Re: Chromium repeat the previous mouse wheel actions from other windows

#25 2024-09-26 13:32:21

Re: Chromium repeat the previous mouse wheel actions from other windows

Board footer