What "mouse performance" means at the browser level
To test mouse performance in a browser, press each physical mouse button inside a single capture target and check the MouseEvent.button integer that the page receives: 0 for Primary, 1 for Auxiliary, 2 for Secondary, 3 for Back, and 4 for Forward. A clean test produces exactly one event per deliberate press, with the label matching the switch you pressed. The browser cannot see switches, sensors, or cables directly — it only sees the event codes the operating system and the page allow through — so checking those codes is one of the most honest performance tests you can run without installing a driver, manufacturer software, or a HID utility. The Mouse Tester is built around that single question: which integer codes reach the page when each switch is pressed, how many times, and in what order? This guide explains what the codes mean, how to run the test deliberately, how to read the total and named counters without overreaching, and where a browser session stops being a reliable verdict on the hardware itself.
This is also why a button-code test is the most useful first step when something feels off. If the page records exactly one event per deliberate press and the label matches the switch, your mouse, the driver, and the browser are cooperating. If the page records nothing, multiple events per press, or a label that does not match the button, something upstream — driver, operating system, extension, remote-desktop client, or hardware — is interfering. The Mouse Tester is built to surface that interference without making claims it cannot back up.
The MouseEvent.button codes your browser actually sees
Every mouse-down event carries a numeric MouseEvent.button field. The Web platform defines five named codes for that field and treats any other integer as either an unknown or a synthetic value. The mapping is standardized in the W3C Pointer Events specification and documented on MDN, so the labels do not change between browsers for the documented integer range. The Mouse Tester uses exactly that mapping, with no remapping and no per-vendor labels.
| MouseEvent.button | Label | Common physical source |
|---|---|---|
| 0 | Primary | Main activation button (usually physical left; can be swapped in OS settings) |
| 1 | Auxiliary | Middle button or wheel click |
| 2 | Secondary | Context-menu button (usually physical right) |
| 3 | Back | Extra thumb button used to navigate history back |
| 4 | Forward | Extra thumb button used to navigate history forward |
Two clarifications matter for a performance test. First, "Primary" identifies the device's main activation button, not the physical left switch — users who remap left and right in their operating system will see code 0 fire from the opposite side, and the Mouse Tester will still label it Primary. Second, button and buttons are different fields. MouseEvent.button identifies the single button that triggered a press or release event; MouseEvent.buttons is a bit field that lists every button currently held during another mouse event such as mousemove. The Mouse Tester listens to button-down events and classifies the single integer code on that event, so it cannot reconstruct a continuous held-button state and does not try to interpret chords. That scope is deliberate: it keeps the result a faithful reading of one event at a time.
Run a button-code performance test
The test is deliberate and short. Open the Mouse Tester, move the pointer into the dashed target, and press each available mouse switch once. Confirm that the page records exactly one event per press and that the label matches the button. If you want to repeat the run with a clean slate, click Reset test before you begin.
- Place the pointer inside the dashed target and press each available mouse button one at a time — Primary, then Auxiliary, then Secondary, then Back, then Forward if your mouse has them.
- For every accepted event, confirm that the total count increased by exactly one and that the matching named count (Primary, Auxiliary, Secondary, Back, or Forward) increased by exactly one.
- Check the Recent list to confirm the order of received events matches the order in which you pressed the buttons.
- Press the same button several more times. Each press should add exactly one event with the same label and nothing else.
- If a button appears missing, repeat the press deliberately inside the dashed area — the target suppresses its own context menu and auxiliary activation so a secondary or middle press does not immediately replace the result with a context-menu action.
- Repeat the same sequence inside the application where the problem occurs (a game, a design tool, a different browser tab), because applications and drivers can map codes differently and may handle extra buttons on their own.
- Click Reset test to clear the in-memory counters before the next run; counts are kept only in the current tab and disappear when you refresh or close it.
Reading the total, named counts, and the Recent list
The Mouse Tester surfaces three pieces of information per accepted event, and each one answers a different question. The total counter is the simplest — it should equal the number of deliberate presses you made. If it overshoots, the browser is delivering duplicate events. If it undershoots, something upstream is swallowing the press before the page can see it.
The named counter is the diagnostic. After a clean run, you should see one count for each button on the mouse, with values matching the number of times you pressed that button. A Primary count of five after five left-click presses means the page is receiving every press and labeling them correctly. A Primary count of five after three left-click presses means the browser is over-reporting; a Primary count of one after five left-click presses means the browser or driver is under-reporting. Either outcome is a data point worth keeping, and the tool cannot isolate hardware, driver, or transport causes from a single browser session.
The Recent list retains the latest eight accepted labels, so you can read the order of received events as a short string of names. Press Primary, Auxiliary, and Secondary in sequence and the list should grow in that order. If the order is scrambled, contains repeats you did not make, or skips a label you know you pressed, that is a data point worth keeping. Independent of the total, the Recent list lets you confirm that the page is interpreting every press as a separate event rather than coalescing them.
When the count says zero — and what it does not mean
A zero count is the most frequently misinterpreted result. The browser, the operating system, an extension, a driver, or remote-desktop software can intercept a button before the page receives its event. Back and Forward buttons are the usual suspects: many browsers bind them to history navigation, so the page never sees the press even though the physical switch worked as designed. Auxiliary and Secondary presses can be intercepted by extensions or by accessibility software that synthesizes its own events.
Preventing the default action inside the test target reduces accidental history jumps, but it cannot override higher-priority browser or system handling. So if a Back or Forward count stays at zero, the answer is not "the switch is broken" — it is "this code never reached this page". To isolate the cause, test the same device in the application where you actually need the button to work, check whether the operating system has reassigned the button, and try a clean browser profile with extensions disabled. A zero count from a single browser session is a real signal about the page, not a verdict on the hardware.
What Mouse Tester does not measure
Button codes are a narrow, well-defined signal. Several things people associate with "mouse performance" are out of scope and need different tools. The Mouse Tester does not measure click speed, double-click intervals, button debounce, polling rate, wireless latency, switch actuation force, pointer movement smoothness, scroll-wheel deltas, or drag behavior. It also cannot certify accessibility, game suitability, or hardware condition. Those claims require timing data or device diagnostics that a normal web page does not have, and the tool does not pretend otherwise.
For pointer movement, scroll, and click timing, the wider Lizely productivity set covers the gap. A Mouse Scroll Test reads the raw horizontal and vertical wheel deltas and counts events in each direction, while a Double Click Test measures the interval between two clicks and keeps a history of recent pairs. Comparing all three results — button codes, scroll deltas, and double-click intervals — gives a more complete picture than any single one. Treat a button-code test as one data point in that broader check, not as a stand-alone repair diagnosis.
For the underlying definitions, the MDN MouseEvent.button reference documents the same integer mapping, and the W3C Pointer Events specification is the authoritative source for the button and buttons fields. Anything outside the integer range 0 to 4 is treated as "unknown" by the Mouse Tester and labeled with its numeric value rather than being silently mapped to a named code, which keeps the result trustworthy even on devices that send synthetic or remapped values.