DevicedialWhich mouse buttons still answer?
Mouse tester
Click every button and roll the wheel over the mouse above. The right button opens no menu here and the middle button starts no auto-scroll โ both are held back so the test can see them.
Inputs that answered
0 / 7inputs
Seven things can answer: five buttons plus the wheel in both directions. A button that never lights up is either broken or bound to something by its own driver.
- Wheel notchesโ
- Notch sizeโ
- Fastest gapโ
- Pointerโ
One gear check a month
MonthlyOne thing a month worth measuring before it fails properly โ a mic that reset itself, a stick that drifts, a switch sending two clicks. Two sentences and the test.
Try also
How do you test a mouse in a browser?
The mouse tester shows every button, wheel and movement event your browser receives, so a control that never lights up is one the page genuinely never heard from. Click each button in turn โ left, right, middle, and the two side buttons if you have them โ then roll the wheel and tilt it.
Two of those need permission to arrive at all. Right-click normally opens the context menu, and the side buttons normally send the browser back and forward through history, so the test suppresses both defaults while it runs. A side button that still does nothing is usually mapped to a macro in the vendor’s own software rather than sending a standard button code.
One number the browser is not allowed to know is DPI. Movement reaches the page already scaled by pointer speed, acceleration and display scaling, so no web page can work backwards to a sensor setting.
A web page sees five standard buttons and no more, each with a number the specification fixes and a bit in the mask of buttons currently held. Three of the five come with a default action attached, and that is the whole reason a mouse test has to ask for them.
| Button | Event number | Bit in the held mask | Default action the test suppresses |
|---|---|---|---|
| Left, primary | 0 | 1 | none, nothing to suppress |
| Middle, wheel click | 1 | 4 | autoscroll on Windows, paste on Linux |
| Right, secondary | 2 | 2 | opens the context menu |
| Side back, X1 | 3 | 8 | navigates history back |
| Side forward, X2 | 4 | 16 | navigates history forward |
The mask is why both columns exist. Press left and right together and the event number reports only the button that just moved, while the mask reads 3 and reports that both are held โ which is how a button stuck down is caught without it ever firing an event of its own.
If a button registers but fires twice from one press, the fault is the switch and the double click test will count it. If movement feels uneven rather than absent, measure the report rate on the polling rate test. For the other half of the desk, start with the keyboard tester.
Frequently asked questions
The side buttons do nothing here but work in games. Why?
Almost always because the vendor software has mapped them to a keystroke or a macro instead of the standard back and forward button codes. A web page only sees buttons three and four; a button that has been turned into Ctrl+C arrives as a keyboard event and never reaches a mouse test at all. Reset the buttons to their defaults in the mouse software and test again.
My scroll wheel jumps back a line every so often.
That is the wheel encoder, not software. Dust or wear inside the optical or mechanical encoder makes it misread the direction of one step, and the page sees a scroll delta with the opposite sign. It is the same class of fault as a chattering button, it gets worse rather than better, and it is fixed by cleaning or replacing the encoder.
Why does middle-click paste text or start an autoscroll?
Because the operating system claimed it first. Windows uses middle-click for autoscroll, and most Linux desktops paste the primary selection. Both are defaults the page has to suppress before it can report the button, which is exactly what this test does โ outside the test, middle-click behaves normally again.
Can I test a wireless mouse this way?
Yes, and every button behaves the same. What differs is the reporting: a 2.4 GHz dongle typically runs at 1000 Hz, while Bluetooth is commonly capped near 125 Hz, and battery saving drops the rate further when the mouse has been still. If movement feels stuttery rather than absent, measure it on the polling rate test instead.
The pointer drifts or jitters when I am not touching the mouse.
The sensor is reading a surface it cannot resolve. Glass, high-gloss desks and reflective mouse pads are the usual causes, and a hair or a smear over the lens does the same. Lift the mouse: if movement events stop instantly, the sensor is fine and the surface is the problem.
Does this work for a trackpad?
It does, since a trackpad reports through the same pointer events. Two differences are worth expecting. There is no middle button, so that indicator will stay dark, and a two-finger scroll arrives as wheel events with much smaller deltas than a notched wheel produces, often dozens of tiny steps where a mouse sends one.
How the test works
Sources:
What the browser can and cannot see
A button code is not a button. The page is told which of five standard buttons was pressed, and a mouse with twelve buttons has to squeeze them into those five or send keystrokes instead. This is why an MMO mouse looks half-dead to any browser test and works perfectly in its own software.
Movement is already processed. By the time a page sees it, the operating system has applied pointer speed, acceleration and display scaling, so the same physical inch of desk produces different numbers on two machines with identical hardware.
What a browser cannot see is often the useful part. DPI, lift-off distance, the sensor model and the firmware version are all invisible here. For those, the vendor software is the only instrument.