Side-button back and forward mappings depend on drivers and are not system-guaranteed

What it is

Mouse side buttons are often labelled back and forward, but whether an application receives them, their numbering, and whether a driver has remapped them depend on hardware, driver, system, and browser. The system layer does not guarantee a uniform semantic, so they are not universally available standard input.

Why it happens

A device reports extra buttons as generic hardware input events, but before that event ever reaches an application it usually passes through a vendor driver layer first — the driver has very likely already intercepted it and converted it into a keyboard shortcut (mapping it to Alt+Left or Alt+Right, say) before forwarding anything to the system. That means an application faithfully listening for "mouse button 3/4" may never see the event at all, because the driver already consumed it at a lower level and carried out the browser's back/forward navigation itself; what the application observes is simply that the page has already changed, not a raw button press. Remote desktops, virtual machines, and web sandboxes insert yet another layer of translation, or drop non-standard buttons outright, so the actual delivery path is considerably more layered than "button pressed, application notified."

Where it stops holding

On controlled hardware and internal enterprise tools, an administrator can uniformly configure the driver mapping for side buttons, and once explicitly enabled the efficiency gain is real. But that says nothing about whether the same behaviour can be relied on for public web pages, mass-market cross-platform software, or shared devices, where device model, driver version, and whether vendor software is even installed are all outside anyone's control. Even when a side-button event genuinely does reach the application, a person may already have remapped it at the system or driver level to some other personal-preference command instead of the product's assumed back/forward, meaning what actually happens when the button is pressed is not entirely under the application's control.

Applying it

• Never make side buttons the only route; retain visible navigation controls, primary-click, and keyboard paths as full equivalents.
• If supporting extra buttons, expose configurable commands instead of hard-coding a back/forward assumption, and degrade gracefully to ordinary navigation when a button is unavailable.
• How to check: test separately on an actual target device, an actual browser, and at least one remote-desktop or virtualization context, to confirm whether the side-button event genuinely reaches the application layer rather than being consumed earlier by the driver or transport path.

Related

• Same group: C1.21.1 The left button carries primary selection, with nearly universal platform semantics · C1.21.2 Middle-button semantics vary by application and lack a unified convention · C1.21.4 Efficiency gains from more buttons depend on remembering nonstandard mappings · C1.21.5 Functions bound only to non-left buttons are unavailable to one-button-mouse and trackpad users
• Nearby: C1.01 Types and properties of pointing devices · C1.23 Input-device compatibility
• Search terms: side button · driver mapping · compatibility