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

[dpz34]

Switching to Wayland and installing imwheel fixes the issue for me

[cstrahan]

I'm suspicious of the packaged version of mutter, or other gnome components. See https://gitlab.gnome.org/GNOME/mutter/-/issues/401

For context, I'm pretty sure I stopped seeing problem back when I upgraded to Ubuntu 19.04 (with GNOME version 3.32 supposedly), and then I didn't see this bug through my use of Pop!_OS 20.04 through 21.10, and now that I'm on 22.04 I'm seeing this bug again.

My belief is that the root cause is a bug in the Chrome source, where it's not handling the tracking of smooth scrolling deltas correctly, but my understanding is that something in mutter papered over the alt-tab issue, which is good enough (as it sounds like the Chrome devs have little interest in resolving this). I no longer use Chrome, but I can't easily avoid Electron apps, unfortunately (VSCode in particular -- as much as like (neo)vim, I depend on VSCode for work in various ways).

What I would be interested in checking is if the particular scrolling issue as described in #2331 (comment) (re overlapping windows) also manifests on 21.04. If so, that would have me thinking that maybe mutter (or whatever was responsible for alt-tab) did something to cajole the target application into taking stock of the current scroll offsets -- like, I don't, some way to synthesize a suitable X event? -- and that workaround wouldn't be feasible in the overlapping case, so I would think that test would tell us something. I just saw that screen captures in #2331 (comment) show that this bug did not show up in 21.10 for the overlapping window scenario.

I know Pop!_OS has plenty of bespoke shortcuts/bindings -- did Pop!_OS change any logic regarding alt-tab? If so, that might be a good place to look, regardless of how benign the changes appear.

Ah, and other thing I just realized, it might help to see if this happens on Ubuntu 22.04.

[markwylde]

This just started happening to me today. I did do an update from the Pop Shop this morning.

Really annoying. :( It does only seem to be effecting Chromium apps for me. Switching between the OS windows seems to work perfectly.

[robertojf2012]

Having the same issue here :/, any new workarounds so far??

[handa26]

It seems installing imwheel solved my problem

[ivandres73]

I have had this problem for a whole year now, it happens when I'm switching apps (chrome and vscode). It is really annoying.

[veryspry]

I started experiencing this bug immediately after upgrading to POP_OS 22.04

[robertojf2012]

Installing imwheel for me didn't fix it :/ I'm still having the scroll issue using vs code and any chromium browser, it's really annoying. I'm using the latest version of Pop!_OS..
How can we scale this??

[handa26]

Hmm, It's been almost a month now since I installed imwheel and for sure I don't see any issue regarding scrolling when switching between vscode and chromium browser. For what I've experience it so far, when I reboot my PC imwheel doesn't automatically run, -- the scrolling bugs come back again :( --, so I setup command imwheel in application startup..from that I never see any annoying scrolling bugs anymore so I assuming imwheel fix the damn problem :)

[robertojf2012]

Probably that's the reason why I keep having the issue, imwheel is not starting everytime I reboot my laptop... I'll try that approach and I'll all let you know if it's fixing the issue..

Can you share to us the command you used for starting up imwheel on boot??

[handa26]

Sure, the command is just imwheel ,you can see in my screenshoot here, hopefully this will also work on your case :)

[robertojf2012]

Thank you so much @handa26 :) I'll try this command and I'll reply again in this post to confirm if it works 👍🏻

[lucasresck]

I'm having this problem on Ubuntu since the upgrade to 22.04, and imwheel wasn't a nice solution for me because I use a notebook trackpad. I also tried other workarounds described at microsoft/vscode#28795, but any of them seemed good enough.

I created a GNOME Shell Extension as a temporary fix:

• Name: Alt+Tab Scroll Workaround
• Link: https://extensions.gnome.org/extension/5282/alttab-scroll-workaround/
• Code: https://github.com/lucasresck/gnome-shell-extension-alt-tab-scroll-workaround

Would love to see if it works for you too!

[handa26]

Wow, thank you for creating this :) that's true, imwheel work badly when I use trackpad lol

[adrianbienias]

Thanks @lucasresck, great work!

[nicholasanthonys]

is the problem still exist?

[adrianbienias]

Without @lucasresck's extension - yes
With extension - no

[robertojf2012]

Hello @handa26 and friends here :), I have tried for sometime already the fix using imwheel
This "fixes" the issue... however it comes with another one, which I think it's worse :/... the scrolling sometimes it just stops working.. even trying to scroll in a website.. it's like it gets stuck. There was a moment I thought it could be my mouse (Because I use wireless) but I tried switching and the problem persisted. Trying scrolling a lot it just moved the website a pixel up or down, which was very annoying.

I did a research on that new issue and I simply found out it was caused by imwheel
What I did was to simply disable imwheel again and everything came back to "normality".

So my conclusion is that this issue is still happening in Pop!_OS...
I'll try the extension from @lucasresck now and I'll report back how it goes 👍🏻

[why-not-try-calmer]

Huge thanks to @lucasresck for his amazing extension -- working with VSCode on Pop is a pleasant experience again! (The fact that we need an extension for this sends an awful message to non-Linux users but nvm)

[lucasresck]

Huge thanks to @lucasresck for his amazing extension -- working with VSCode on Pop is a pleasant experience again! (The fact that we need an extension for this sends an awful message to non-Linux users but nvm)

Happy to help!

[mattemoore]

@lucasresck mad props for this. I was really frustrated with this issue and you fixed it. Thanks.

[dougkusanagi]

I haven't seeing someone comment so i'll, vscodium doesn't have this issue, maybe another hint for solve the problem. And thanks @lucasresck for the extension.

[lucasresck]

And thanks @lucasresck for the extension.

You're welcome! Happy to help

[mikkorantalainen]

All applications that are based on Chromium source code (e.g. Google Chrome, VS Code, all Electron apps) suffer from this bug. Steps to reproduce can be found at https://bugs.chromium.org/p/chromium/issues/detail?id=608246#c68 and my guess about the root cause is described at https://bugs.chromium.org/p/chromium/issues/detail?id=608246#c78

[lucasresck]

I'm having this problem on Ubuntu since the upgrade to 22.04, and imwheel wasn't a nice solution for me because I use a notebook trackpad. I also tried other workarounds described at microsoft/vscode#28795, but any of them seemed good enough.

I created a GNOME Shell Extension as a temporary fix:

• Name: Alt+Tab Scroll Workaround
• Link: https://extensions.gnome.org/extension/5282/alttab-scroll-workaround/
• Code: https://github.com/lucasresck/gnome-shell-extension-alt-tab-scroll-workaround

Would love to see if it works for you too!

Hi, folks! A few users have been reporting that the problem is back on Pop!_OS when Alt+Tab Scroll Workaround extension is active (lucasresck/gnome-shell-extension-alt-tab-scroll-workaround#16). Have you also experienced this?

[veryspry]

Hi, folks! A few users have been reporting that the problem is back on Pop!_OS when Alt+Tab Scroll Workaround extension is active (lucasresck/gnome-shell-extension-alt-tab-scroll-workaround#16). Have you also experienced this?

I have, unfortunately and haven't had time to do further testing or try and fix it 😔

[stringbeans]

just wanted to comment that as of today, with Pop!_OS 22.04 LTS, i am still experiencing this issue :(

[tibbing]

I have this problem too, has been like this for years over multiple machines, one of the most annoying issues with PopOS. Haven't found a stable workaround so far.

[lucasresck]

Haven't found a stable workaround so far.

Hi, have you tried the Alt+Tab Scroll Workaround GNOME Extension? If so, did it not work?

[tibbing]

Haven't found a stable workaround so far.

Hi, have you tried the Alt+Tab Scroll Workaround GNOME Extension? If so, did it not work?

Thanks, I hadn't tried that one. I installed it but doesn't seem to do anything. Perhaps it's not compatible with Edge that I'm using?

[lucasresck]

@tibbing, I don't think Edge is the problem. Some users have reported issues in Pop!_OS, which may be related to your problem.

I created the extension to solve this specific bug in Ubuntu and it works until today. We can try to have this working in your machine as well, as it has already worked in Pop!_OS in the recent past—let me know.