I discovered this thread
Basically if I run
xev | grep -e "ButtonPress" -e "ButtonRelease" and move the mouse over the window while scrolling I can clearly see the events, which means it's a desktop environment / window manager problem.
People discussing more about the issue here https://gitlab.freedesktop.org/xorg/driver/xf86-input-libinput/issues/9
If I simply launch
firefox from a terminal, I experience scroll events being ignored while moving the mouse, but if I do instead a
GDK_CORE_DEVICE_EVENTS=1 firefox then everything works as expected.
The thread at https://forums.virtualbox.org/viewtopic.php?f=3&t=79002&start=15 contains a more interesting reply from a bugmenot user:
xinput should show the devices X believes are sending events:
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ VirtualBox mouse integration id=9 [slave pointer (2)]
⎜ ↳ VirtualBox USB Tablet id=10 [slave pointer (2)]
⎜ ↳ ImExPS/2 Generic Explorer Mouse id=12 [slave pointer (2)]
⎣ Virtual core keyboard id=3 [master keyboard (2)]
↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)]
↳ Power Button id=6 [slave keyboard (3)]
↳ Sleep Button id=7 [slave keyboard (3)]
↳ Video Bus id=8 [slave keyboard (3)]
↳ AT Translated Set 2 keyboard id=11 [slave keyboard (3)]
Apparently mouse events are divided between the
VirtualBox mouse integration and the
VirtualBox USB Tablet device. One of them receives the movement events while the other the scroll events. In some applications once a source of events becomes active, the other one is ignored.
The solution is to disable
VirtualBox mouse integration (id=9 in my listing above) either temporarily with
xinput disable 9
or completely by adding a file, for example
Identifier "Fix VBox scroll wheel"
MatchProduct "VirtualBox mouse integration"
Option "Ignore" "on"
MatchProduct directive is exactly the string output from