Scrolling in one app carries over the scroll delta when switching to a new app and scrolling

[japostoles]

Distribution (run cat /etc/os-release):
NAME="Pop!_OS"
VERSION="22.04 LTS"
ID=pop
ID_LIKE="ubuntu debian"
PRETTY_NAME="Pop!_OS 22.04 LTS"
VERSION_ID="22.04"
HOME_URL="https://pop.system76.com"
SUPPORT_URL="https://support.system76.com"
BUG_REPORT_URL="https://github.com/pop-os/pop/issues"
PRIVACY_POLICY_URL="https://system76.com/privacy"
VERSION_CODENAME=jammy
UBUNTU_CODENAME=jammy
LOGO=distributor-logo-pop-os

Issue/Bug Description:
This is a tough one to explain, so I'll do my best.

Note: Using a touchpad / 2-finger scroll. This behavior didn't happen in the previous verison of POP_OS

I'll use two apps as an example: (A) Chromium and (B) VSCodium, but it seems to happen with any app that scrolls. To start, I'll have both (A) and (B) open with a long document. If I scroll down, let's say three screen-fulls in app (A), when I switch to app (B) and then scroll down, the scrollbar jumps down the exact same amount of "pixels" that were scrolled in app (A).

It's almost as if the scroll y offset is carrying over to the other app after an ALT-TAB.

Said another way:

• Scrolling down 500 pixels in (A), switch to app (B) - scrolling down jumps 500 pixels at first, then scrolls normally. If I scroll up in (B) after scrolling down in (A), scrolling up jumps DOWN 500 pixels first and then scrolls up normally.

[jacobgkau]

I'm able to recreate this on an Oryx Pro only when the two apps are overlapping each other, the mouse cursor is placed in the overlapping area, and the mouse cursor is not moved outside of the second app after switching and before attempting to scroll.

[japostoles]

Great catch on the overlapping windows! That's the same behavior I'm seeing here, exactly.

[adrianbienias]

Same here

Reproduced on Live USB on Pop!_OS 22.04
https://thumbs.gfycat.com/NiftyAromaticDwarfmongoose-mobile.mp4 (issue starts around ~ 00:15)

The bug is not present in Pop!_OS 21.10 (also tested on Live USB)
https://thumbs.gfycat.com/LinedDamagedAmethystgemclam-mobile.mp4

I assume it has something to do with Chromium/Electron apps. I'm able to reproduce it when switching from the Firefox browser to an Electron app like VSCode or Signal, but when switching back from the Electron app to Firefox, Firefox's scroll isn't affected.

[felixroos]

I have the same issue. It always messes up the scroll position when switching between vscode / chromium, which is really annoying for coding. The same happens for discord, slack and ytmdesktop, which I believe are all chromium based (electron apps).
As already mentioned, it looks like scrolling anywhere (also non chromium) will shift scroll position in any chromium based app on the next scroll event, so I assume there are some listeners that should be unsubscribed when the window gets inactive. I also noticed switching windows within the same application will work (tested with multiple chromium windows & multiple vscode windows separately).
I am not sure if this is an issue with pop os or gnome or chromium..

EDIT: Just found out this is not an issue when using Wayland

[adrianbienias]

I can confirm that switching to Wayland helps.
But for me, it generates new problems e.g. Conky doesn't work on Wayland, nor Touchegg.

Enabling Wayland: https://unix.stackexchange.com/questions/700938/enable-wayland-in-popos-22-04
Then on login screen, after picking the user click cog icon and switch to Wayland

[japostoles]

This is super frustrating, it makes my machine unusable for development due to the disorienting nature of the bug.

I'm fairly worried at this point, here's a 5 year old open bug filed against VSCode with the same problem:
microsoft/vscode#28795

If anyone has any ideas on where the problem may lie, I'm going to start digging in and see if I can come up with a patch.

[japostoles]

Found on the linked thread -- for whatever reason if you install imwheel and run it, the problem goes away, although the scrolling is a bit janky. Still better than the jumping behavior, and at least you don't have to switch to wayland if that's causing issues.

What's weird is that imwheel seems to demonstrate the bug as you are scrolling within the same app. If you scroll super slow you'll see that it'll jump about the same amount you've scrolled in the same direction. Perhaps a clue to where the problem is?

One more workaround (right click and left click before switching apps): microsoft/vscode#28795 (comment)

[canadaduane]

Thank you, @japostoles for your determination. I've been experiencing this for a long time and thought it was just me. It's hard to believe the bug is more than 5 years old! If I can help test or brainstorm let me know.

[canadaduane]

More info: https://bugs.chromium.org/p/chromium/issues/detail?id=608246

Also attaching another video using the eventTest page linked. This one is more interesting.

I mentioned that the extra scrolling wasn't firing additional javascript scroll events. It still doesn't, but look at the deltaY value.

Each 'scroll click' of my mouse wheel generates output with deltaY as either 53 (positive) or -53. When this issue happens, those events are shown to have deltaY of multiples of 53 or -53, depending on how far I scroll. At one point it shows a deltaY of 106, which was me performing a single mouse wheel 'scroll click' on the xev window, then alt-tabbing and doing another single click on the Chrome window.

More info:

If xf86-input-libinput (on Arch; xserver-xorg-input-libinput on Ubuntu) is installed, this bug manifests. Uninstalling this package and replacing it with xf86-input-evdev (or xserver-xorg-input-evdev on Ubuntu) fixes this issue completely. The evdev package is installed by default on Ubuntu and Xubuntu, and not the libinput package, which explains why I couldn't replicate this in my VM tests before.

Unfortunately the xf86-input-libinput package is necessary in gnome-shell to be able to configure mouse settings graphically, but I hope this is a matter of configuring the package properly.

Edit to add last seemingly relevant note:

If it just happens on Xorg, IMHO it's a strong indication it's not really mutter's fault (if anything, it's doing the focus change in a way the application didn't cater of, but there's nothing to "fix" about it)
With Xorg smooth scrolling, scroll axes are transmitted as 2 dx/dy axes, which accumulate the scroll performed thus far. The catch is that this state is global to the whole session, if you scroll on an app, go somewhere else and scroll, and go back to the app, it will see values affected by the scrolling outside.
Toolkits (I'll include electron here) must be smart about this, and reset their own state when the pointer enters the application so that the changes in dx/dy that happened since the last time are ignored. This is a known issue with XI2.3 smooth scrolling.

My gut feeling is that chromium handles this partially (i.e. resetting its scroll state on certain pointer crossing events), but our alt-tab paths happen to trigger a crossing event with a mode/detail that goes unheard by them. Can't blame them for this, it's tricky to get the details right. Eg. gtk errs on the other side, making the first scroll event received after the pointer entered the window ineffective, just to get a baseline for dx/dy for all following ones: https://gitlab.gnome.org/GNOME/gtk/blob/master/gdk/x11/gdkdevicemanager-xi2.c#L1914

[SeekerNik]

Found on the linked thread -- for whatever reason if you install imwheel and run it, the problem goes away, although the scrolling is a bit janky. Still better than the jumping behavior, and at least you don't have to switch to wayland if that's causing issues.

What's weird is that imwheel seems to demonstrate the bug as you are scrolling within the same app. If you scroll super slow you'll see that it'll jump about the same amount you've scrolled in the same direction. Perhaps a clue to where the problem is?

One more workaround (right click and left click before switching apps): microsoft/vscode#28795 (comment)

After installing imwheel the problem still persist.
More info:
The scroll position of previous application is retained even after switching to other application.
example -: In chrome and vs-code let's say I am on top of the page and in chrome when I scroll down to botton of a page and switch to vs-code and started to scroll it instantly get to the bottom of the page.

[adrianbienias]

It's worth noticing that the issue exists on the latest version 22.04 but not on the older ones 21.10 or 21.04 (I was using those versions and didn't have that bug until upgrading to 22.04).

So Chromium bug is one thing, but things that changed (Gnome version, kernel version, something else?) are also a culprit for that bug.

[LeMisterV]

Hi,

I'm using Ubuntu, not Pop-OS. But I get the same bug.
One way to fix it for me is to stop using nvidia proprietary drivers and use Nouveau instead.
I don't know if this can help.... is this bug related to nvidia driver ? anyone without nvidia driver having this bug ?

[adrianbienias]

In my case that can't be Nvidia drivers. I have only one, integrated graphic card Mesa Intel® HD Graphics 520 (SKL GT2).

[SeekerNik]

This bug has something to do with x-org because switching to Wayland fix this issue.
Workaround for now - switch to Wayland