The feature you are talking about is called "Auto-Scrolling". It lets you press and hold the middle mouse button and move your mouse to scroll smoothly. In Linux, the default behavior for this action (pressing middle mouse button) is generally pasting text.
However, there is a preference setting in Firefox and an extension available for Chrome/Chromium which would let you use the middle mouse button for scrolling and activate this feature.
Firefox
Open the "Options" tab: "≡" (Open menu) → "Options".
Navigate to "General" (it should open to "General" by default).
Scroll down to "Browsing".
Under "Browsing", you will find the "Use autoscrolling" option. Put a check mark beside this to activate this functionality in Firefox.
Or just search for "autoscrolling" using the search bar.
In older versions of Firefox: "Edit" → "Preferences" → "Advanced" → "General" → "Browsing" → "User autoscrolling".
Click on the below for a larger image.
Chrome/Chromium
For Chrome/Chromium we can use an Extension called "AutoScroll" (from kaescripts.blogspot.com).
Go to this link on Chrome Web Store (obviously using Chrome/Chromium).
Click on the button labeled "+ ADD TO CHROME" to install this extension.
Click on "Add" in the Confirmation Dialog Box.
Other Applications
As far as other applications are concerned, I haven't yet found a solution for them. Anyways, it's the tall webpages that create most of the problems for which both Firefox and Chrome/Chromium have a solution.
In order to make the horizontal scrolling work, I had to remap the mouse buttons. Check the mapping using xmodmap -pp:
[sly@SlyLap ~]$ xmodmap -pp
There are 24 pointer buttons defined.
Physical Button
Button Code
1 1
2 2
3 3
4 4
5 5
6 6
7 7
8 8
9 9
10 10
11 11
12 12
13 13
14 14
15 15
16 16
17 17
18 18
19 19
20 20
21 21
22 22
23 23
24 24
Use xev to find out the button codes for horizontal scrolling:
[sly@SlyLap ~]$ xev
...
ButtonPress event, serial 29, synthetic NO, window 0x5400001,
root 0xad, subw 0x5400002, time 173143560, (21,37), root:(25,493),
state 0x0, button 8, same_screen YES
...
ButtonPress event, serial 29, synthetic NO, window 0x5400001,
root 0xad, subw 0x5400002, time 173126732, (21,37), root:(25,493),
state 0x0, button 9, same_screen YES
From here I can see the left/right button codes are 8/9. Since the synaptics driver uses the buttons 6/7 for left/right scrolling, I simply needed to swap the order of how the buttons are declared. To change the mapping:
xmodmap -e "pointer = 1 2 3 4 5 8 9 6 7 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24"
This will swap 8/9 6/7 which will make the horizontal scrolling work.
Best Answer
I discovered this thread https://bbs.archlinux.org/viewtopic.php?id=223470
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
firefoxfrom a terminal, I experience scroll events being ignored while moving the mouse, but if I do instead aGDK_CORE_DEVICE_EVENTS=1 firefoxthen 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:
Running
xinputshould show the devices X believes are sending events:Apparently mouse events are divided between the
VirtualBox mouse integrationand theVirtualBox USB Tabletdevice. 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 withor completely by adding a file, for example
/usr/share/X11/xorg.conf.d/50-vbox-mouse-fix.conf:(the
MatchProductdirective is exactly the string output fromxinput).