Scrolling in Chromium stops working when moving mouse when running in virtual machine

[Lars Rustand]

When Ubuntu is running in a virtual machine scrolling in Chromium stops working when moving the mouse even the slightest. Also the first scroll step is always ignored after moving the mouse. This results in a very uneven scrolling which is very difficult to use. Scrolling works perfectly in other applications like for example Firefox.

This bug seems to have appeared in Ubuntu 16.04.0, as all Ubuntu releases before 16.04 works correctly, while all releases after 16.04 are affected by this bug. Ubuntu is not the only distro that has this bug, but there are also several distros that are not affected by it.

My current testing have shown the following distros to be affected:
- Arch Linux
- Linux Mint 20 Cinnamon
- Manjaro XFCE 20.1
- OpenSUSE Tumbleweed
- Ubuntu 16.04, 18.04, 20.04

And the following distros and operating systems are NOT affected:
- Centos 8
- Debian 10 (Buster)
- DragonFly BSD 5.8.1
- Fedora 32
- GhostBSD 20.08.04
- Ubuntu 12.04 to 15.10
- Windows 10

The fact that there are current updated distros that are unaffected indicates to me that this is probably not a bug in Chromium upstream, but I've not been able to pinpoint whether the problem is caused by something in the Chromium packaged by Ubuntu or some other difference in the system like the kernel or system libraries.

I have already reported the bug to Chromium, link to the bug report here: https://bugs.chromium.org/p/chromium/issues/detail?id=1128405.

There is also another bug report here: https://bugs.chromium.org/p/chromium/issues/detail?id=1100179

I've already spent well over a week trying to troubleshoot this issue. I'm willing to do most of the work myself, but I really need some guidance as to what are the best next steps in troubleshooting this. Any help would be greatly appreciated!

[Olivier Tilloy (osomon)]

Comment #14 in https://bugs.chromium.org/p/chromium/issues/detail?id=1128405 suggests that this might be a hardware issue. Are you able to observe the problem with other mouses?

[Lars Rustand (lrustand)]

Well, that guy probably had a hardware issue, but this is not a hardware issue. I have tried several mice, all of them are acting the same way. Also, the fact that not all apllications are affected, and the fact that not all operating systems are affected at all should make it pretty clear that this is a software issue.

The fact that this only happens inside virtual machines suggest that it might be more of a driver/kernel issue or somehow related to the guest handling of the simulated mouse in virtual machines.

I have read somewhere that the virtual mouse is represented by two mouse devices, one which controls the movement and the other controls the scrolling (and possibly the buttons, can't remember the details).

I have however recently found an old forum thread https://forums.virtualbox.org/viewtopic.php?f=3&t=79002&sid=ae3639b6f48a63da8441d6582880d2e7&start=15 which seems to be referring to the same issue. Here there are several workarounds being suggested by different people, while the one that worked for me was using imwheel. I have no idea how or why this works, but this does at least makes my scrolling work again.

[Lars Rustand (lrustand)]

The forum post also says it might be somehow related to either evdev or libinput or possibly both.

[Olivier Tilloy (osomon)]

You linked to a virtualbox forum thread, but I realize you didn't specify which virtualization technology you're using. Is this virtualbox too? If so, does uninstalling the guest additions make a difference?

[Lars Rustand (lrustand)]

I'm not using the virtual machine anymore so I can't check it right now, but it shouldn't be hard to reproduce if anyone wants to follow up.

Like I mentioned in the linked Chromium bug, this happens in both Virtualbox and VMWare, so this is not specific to either one of them. I can't remember if I ever tried uninstalling guest additions (although I think so).

[Paul White (paulw2u)]

Both upstream bugs were closed sometime ago as 'WontFix'

The reports agaisnt ArchLinux and openSUSE tasks won't
go anywhere as neither distribution uses Launchpad for
bug reporting so closing as 'Invalid'.

Reporter no longer uses a VM so changing the status of the
remaining tasks to 'Incomplete' so that the bug report will
expire if there are no further comments in the next 60 days.

[Launchpad Janitor (janitor)]

[Expired for qutebrowser (Ubuntu) because there has been no activity for 60 days.]

[Launchpad Janitor (janitor)]

[Expired for chromium-browser (Ubuntu) because there has been no activity for 60 days.]

[Launchpad Janitor (janitor)]

[Expired for falkon (Ubuntu) because there has been no activity for 60 days.]