How to solve a scrolling misbehavior after doing Alt+Tab?

Question

most of the time I do an Alt+Tab (switch windows), go from browser (chrome) to Visual Code and vice versa, mouse scrolling misbehaves, it jumps to somewhere in the page, either way down the current scroll position, or way up, any thoughts on what's going on?

Answer 1

Installing and running imwheel fixes the problem for me.

$ sudo apt-get install imwheel
$ imwheel
INFO: imwheel started (pid=80085)

You have to start it at every boot (or add it at the applications to start).
pgrep -lf imwheel to see if it's running ; you can stop it with pkill imwheel.

/!\ It disables the zoom by Ctrl + wheel in applications (Firefox, Chromium, LibreOffice, PDF reader...)
(Maybe a setting in imwheelrc could fix that)

Answer 2

What you described is still an unsolved bug. When scrolling in one window, its scroll is buffered and repeated in another window after Alt+Tab. As you exemplified, it happens between Chrome and VS Code.

Fortunately, there's a GNOME extension as a quick fix for that: Alt+Tab Scroll Workaround. Just activate it and it should solve the problem.

I developed this extension to, among other things, surpass the imwheel's problem of scrolling "stepwise" while using a notebook touchpad.

Answer 3

If you are asking for a solution, It's still an unsolved bug. But if you wonder why such a thing may happen, I think the reason is that scroll position is being unique for all windows, or it's being changed for all of them when you scroll. for example, if you scroll up in a window a little, then go to the other one and start scrolling, the bar jumps a little upper and starts moving from there, showing that scroll changes from the other tab are being applied to the new one too.

Answer 4

This is a bug in Chromium source code. See https://bugs.chromium.org/p/chromium/issues/detail?id=608246#c68 for steps to reproduce. There's a long discussion about this issue at https://github.com/microsoft/vscode/issues/28795 and the root cause is explained in an blog post https://who-t.blogspot.com/2012/06/xi-21-protocol-design-issues.html from year 2012 which explains that the first scroll event after switching windows should be ignored. GTK has this workaround implemented for all GTK apps, but Chromium uses custom implementation which is missing this workaround.

There has been comments that this doesn't happen with Wayland which makes sense because the design bug is in X11 XI protocol. And if you have NVIDIA GPU, then Wayland is not a good option because the NVIDIA drivers are often unstable on Wayland.

Answer 5

I solved this problem by logging in with configuration Ubuntu on Wayland instead of simply Ubuntu. Something like that. Image quality is low but you'll get the point.

That means I use Wayland instead of xorg but changing file /etc/gdm3/custom.config does not seem to solve the problem as stated here.

Answer 6

If you are not too attached to GNOME, switching to Unity solves the scroll issue on the mouse & trackpad:

sudo apt install ubuntu-unity-desktop

Source: https://itsfoss.com/use-unity-ubuntu-17-10/#:~:text=Switch%20from%20GNOME%20to%20Unity%20in%20Ubuntu%2017.10,option%20to%20switch%20to%20Unity

---

To restore the natural scrolling and other trackpad features, also install synaptics drivers:

sudo apt install xserver-xorg-input-synaptics