Mycelgrid
Mouse Tester

MOUSE TESTER / GUIDE

How Browser Mouse Testing Works

A browser can observe useful mouse behavior without a hardware driver API: button roles, pointer movement, wheel events, and event timing. Those signals are enough for a practical first-pass mouse check, but they do not expose every electrical or USB detail of the device. Good diagnostics therefore separate what the browser observed from what the hardware itself may be doing.

Mouse buttons are roles, not guaranteed physical positions

Browser mouse events identify roles such as primary, auxiliary/middle, secondary, Back, and Forward. Primary is commonly the physical left button and Secondary is commonly the physical right button, but left-handed settings and remapping utilities can reverse or change those relationships. Mouse Tester therefore labels the browser roles first and treats physical-position wording as a hint.

How the scroll wheel is observed

Wheel events expose horizontal and vertical deltas plus a delta mode. The mode can express values in pixels, lines, or pages. Because operating systems and browsers can transform physical wheel motion before the page receives it, the app uses wheel input mainly to confirm direction and event behavior rather than claiming a physical scroll distance.

How browser-observed pointer rate is estimated

During active movement, the app records high-resolution browser event timestamps and looks at positive intervals no longer than the active-movement gap limit. It uses the median interval because one delayed event is less likely to distort a median than an arithmetic mean.

Estimated browser pointer rate = 1000 ÷ median active interval in milliseconds

For example, a median interval of 2 ms corresponds to roughly 500 browser-observed updates per second. A median interval of 1 ms corresponds to roughly 1000 updates per second.

Why this is not the same as USB polling rate

A mouse may report to the operating system at one cadence while the browser receives a different sequence of pointer events. Browsers may coalesce movement updates, the operating system may schedule delivery, and high-resolution pointer features vary by browser. Therefore the displayed rate is deliberately called a browser-observed pointer rate, not a certified USB polling rate.

How movement stability is calculated

The app takes active event intervals, finds their median, then finds the median absolute deviation from that median. Stability is a normalized descriptive score:

Stability = 100 × (1 − min(1, median absolute deviation ÷ median interval))

A higher score indicates more even browser-event spacing in that sample. It does not establish sensor quality or gaming performance by itself.

How the rapid-repeat screen works

The 10-click check records the gap between intentional primary-button presses. Gaps below 80 ms are surfaced as rapid pairs. That threshold is intentionally described as a screening rule rather than a universal double-click hardware standard. A rapid pair can result from the device, the operating system, software remapping, browser behavior, or the user actually clicking twice quickly.

What makes an abnormal result more convincing

Repeatability across environments matters. If an unexpected button count or rapid pair appears once, repeat the same check. If it appears again, try a second browser. If practical, try another computer or connection and temporarily disable remapping/vendor software. A behavior reproduced across several environments provides stronger evidence than one browser session.

Why side buttons can be difficult to test

Back and Forward buttons are often tied to navigation. Some platforms deliver a button event to the page; others may reserve the action or navigate before the page can use it. Failure to observe a side button is therefore not sufficient proof of hardware failure.

Why browser mouse testing cannot measure DPI directly

Pointer coordinates are transformed by operating-system acceleration, sensitivity, browser zoom, display scaling, and screen geometry. Without a calibrated physical-distance workflow, browser pixels do not provide a trustworthy direct sensor-DPI measurement.

Why browser event timing is not end-to-end input latency

Event timestamps describe when browser-observable events occur. True input latency includes physical switch actuation, device firmware, radio or cable transport, USB scheduling, operating-system handling, browser scheduling, application processing, rendering, display scanout, and pixel response. This app does not claim to measure that entire chain.

Open Mouse Tester to observe your own input, then reset and repeat anything unusual.