Scrolla upp blir som att klicka tillbaka i Waterfox och Firefox

I qutebrowser fungerar det inte att scrolla alls.

Har inte problemet själv, men hittade en Reddit-tråd för folk som hade det på Firefox (som är släkt med Waterfox):

https://www.reddit.com/r/firefox/comments/1nsmkww/scroll_wheel_triggering_back_navigation

Ett konkret tips på en inställningsändring därifrån:


Om jag förstått inställningen rätt ska den egentligen bara påverka vad som händer om man håller ner Alt samtidigt som man scrollar med hjulet, men för dem som har det här problemet utan Alt tycks det också kunna hjälpa.

Testade lite olika ai-modeller och prompter, denna verkar rimligast:

...based on my access to FreeBSD bug trackers and community discussions, I can confirm: yes, this is a very well-known and documented bug. However, it is generally not a bug in Waterfox or Fluxbox itself. It is a deeply entrenched Xorg/libinput mouse mapping issue specific to FreeBSD (and exceptionally common if FreeBSD is running as a guest in VirtualBox, though it happens on bare metal hardware too).

Here is exactly what is happening and how to help your user fix it.

The Root Causes
1. X11 Button Confusion
In X11 environments, scrolling the wheel up and down is supposed to be mapped to mouse buttons 4 and 5. The "Back" and "Forward" side-buttons on modern mice are mapped to 8 and 9. On FreeBSD, Xorg frequently misinterprets the scroll wheel's up/down hardware inputs as buttons 8 and 9. When the browser receives a "button 8" event, it executes a "Back" navigation.

2. Ghost Modifiers
Waterfox (like Firefox) is configured by default to navigate back or forward if the user scrolls the wheel while holding Shift or Alt. If the X server or Fluxbox has a "sticky" modifier state or misreports key presses, a regular scroll gets interpreted as Alt + Scroll, triggering the back action.

How to Fix It
You can offer the user a few different angles to solve this, depending on whether they want to fix it at the OS level or the browser level.

Fix 1: The xmodmap Override (Recommended)
This fixes the root issue at the X11 level. Have the user run xev from the terminal and scroll the wheel to see if it spits out button 8 instead of button 4. If it does, they need to disable the ghost buttons.

Tell the user to create or edit a file named .xmodmap in their home directory.

Add the following line to disable buttons 8, 9, and 10: pointer = 1 2 3 4 5 6 7 0 0 0

Apply the fix by running: xmodmap ~/.xmodmap

Note: If they have a high-end mouse with 12 buttons, they should use pointer = 1 2 3 4 5 6 7 0 0 0 11 12 instead to keep the rest of their buttons working.

Fix 2: Waterfox about:config Tweaks
If the user actually relies on physical back/forward side buttons and doesn't want to kill them via xmodmap, they can neutralize the behavior directly in Waterfox.

Instruct the user to type about:config in the Waterfox address bar and accept the risk warning.

Search for the preference mousewheel.with_alt.action.

Change the value from 2 (History navigation) to 1 (Scroll contents) or 0 (Do nothing).

Repeat the exact same step for mousewheel.with_shift.action.

Search for mousebutton.4th.enabled and toggle it to false.

Fix 3: Check Fluxbox Keybinds
While less likely to cause this specific browser behavior, it is worth checking the ~/.fluxbox/keys file. Users often map Mouse4 and Mouse5 to workspace switching (e.g., OnDesktop Mouse4 :PrevWorkspace). If there is a malformed global bind hijacking the scroll wheel, it can occasionally bleed into application windows and cause erratic focus or navigation issues.

Nej, men byt operativsystem så du får fungerande webläsare!