Short answer: open the mouse test and press each button once — left, middle (press straight down on the wheel), right, and any side buttons. Every press that reaches the browser lights up its label: Left, Middle or Right, with any extra button shown as Button N. A button that never lights up while the others do is the one to look at. The test confirms which buttons register — it does not measure how fast they poll or how they feel.
How to test all the buttons
- Left and right — click each once. These are the two the browser sees most reliably, because a left click also fires the normal
clickevent and a right click raises the context menu. - Middle — press straight down on the scroll wheel until it clicks. That is a real, separate button; a wheel that scrolls but does not click when pressed is a middle-button problem, not a scroll one (that is what the scroll wheel test is for).
- Side buttons — if your mouse has back/forward thumb buttons, press each. The browser only sees them if the system forwards them as ordinary button events (see the limit below).
- Watch for the opposite problem while you are there: a single press that registers twice is not a dead button but double-click chatter, and a button that never fires is covered in how to check which button is not registering.
What each button looks like to the browser
The web platform gives every button a fixed number. When you press one, the browser reports a button value on the event:
- 0 — left (primary)
- 1 — middle (the wheel click, also called auxiliary)
- 2 — right (secondary)
- 3 — the fourth button, usually side back
- 4 — the fifth button, usually side forward
One detail trips people up: the separate buttons field, which reports everything currently held down, uses a different order — left is 1, right is 2, and middle is 4. That mismatch is a quirk of the spec, not of your mouse. It also explains why the labels matter more than the raw numbers, and why the test shows plain Left / Middle / Right instead of asking you to decode indices.
Only a left click fires the ordinary click event. Middle, right and side presses come through as auxclick (or, for the right button, the contextmenu event), which is exactly why a page that only listens for click can look like it is ignoring your other buttons when they are working fine.
Side and extra buttons: why they sometimes don’t show
A side button that does nothing in the test is not automatically broken. Many gaming and multi-button mice route their thumb buttons through their own driver — bound to a macro, a keystroke, or navigation — so the button never reaches the browser as a mouse-button event at all. In that case the test is telling you the truth: from the browser’s point of view, no button event arrived. To tell “remapped” from “dead,” check the mouse’s own software: if the button is assigned to a macro it is working as configured; if it is set to a plain back/forward and still shows nothing anywhere, that points at the button or the connection.
What this test can and can’t tell you
The mouse test is a click-by-click, cross-browser check of which buttons register and how they are labelled. That is the reliable part, and it runs the same in every browser. Be clear about what it does not do:
- It cannot measure polling rate, DPI, or latency — those live below the browser, in the device and the operating system, and no web page can read them (see what a browser reports when you think it is measuring polling rate).
- It cannot judge switch feel, travel, or bounce timing. It sees that an event arrived, not the millisecond-level mechanics behind it.
- It reports what your system chose to send. A remapped or driver-handled button is a configuration fact, not a hardware verdict.
Used for what it is — a fast, honest confirmation of which buttons fire — the mouse button test answers the question most people actually have: is this button working right now, in this browser, on this mouse? For click-speed instead of button coverage, the CPS test and drag test cover the other things a mouse is asked to do.