Wheel diagnostic · direction, gaps and bursts

Mouse wheel test

A guided four-phase check for a mouse wheel that scrolls the wrong way, skips, stutters or drops input. You declare the direction, the test records what your browser actually received, and the report separates the two instead of handing you a verdict.

Runs entirely in this browser tab. Nothing is recorded to a server or uploaded.

Local measurement workbench

Wheel event console

browser-wheel-events-v2
Diagnostic · phase 1 of 4Ready

Normal pace · down

Scroll down at your normal steady pace

After arming, the first wheel event starts a 5 s window. Keep the declared down direction and normal pace until it ends.

5.0 sof 5 s
Direction timelineposition = monotonic event time

0 recent browser events shown. Up events appear above the axis, down events below it, and horizontal-only and true-zero events use distinct marks on the axis.

Events received
0
Average event rate
0.0 events/s
Latest direction
Latest reported delta

Timer starts on the first wheel event. Events at or after the exact boundary are excluded. While armed or recording, wheel input anywhere on this page is captured. Press Escape or use Cancel run to stop.

How the wheel diagnostic works

The protocol runs four short phases — down and up at your normal pace, then down and up at a controlled faster pace. Declaring the direction before each phase is the whole point: it lets the report distinguish an event that disagreed with your intent from one that simply followed a change of mind mid-stroke. A phase that receives too few events to judge is marked inconclusive rather than scored.

Everything is measured from browser WheelEvent data: direction per event, the reported delta and its unit, and the interval between consecutive events. Nothing is converted into physical notches, because a browser genuinely cannot see them.

The three patterns worth retesting

Reversals inside a phase

Events travelling opposite to the direction you declared. A handful mid-stroke suggests a dirty or worn encoder; every event flipped means a natural-scrolling setting, not a fault.

Gaps and dropouts

Long intervals inside a continuous stroke. Debris in the encoder slot, a failing sensor, or a wireless link on a weak battery all produce this shape.

Burst delivery

A pause followed by a clump of events with near-zero intervals. Usually the page or the system coalescing input under load rather than the mouse itself — retest on a quiet tab.

Isolate the fault before you replace anything

  • Repeat the same protocol, same duration, same declared input category at least three times. A single odd run is noise; a repeated pattern is evidence.
  • Retest in a second browser. Event coalescing and extension behaviour are per-browser; a hardware fault is not.
  • Move to another USB port, and for a wireless mouse swap the battery and move the receiver closer before drawing conclusions.
  • Try the mouse on another computer. If the pattern travels with the mouse, it is the mouse.
  • Check your buttons and polling while you are here with the mouse test, which covers double-click chatter and polling rate.

The full symptom-by-symptom walkthrough lives in the scroll wheel troubleshooting guide, and the methodology page explains exactly what the classifier does and does not claim.

Wheel works, but you want a number?

If the diagnostic comes back clean and you are really here to find out how fast you can scroll, the scroll speed test starts the moment you hover it and reports pixels per second with a rating tier, and the scrolls per second test reports the SPS figure used across the click-speed category.

Mouse wheel test questions

Run the guided protocol above: four short phases, scrolling down then up at a normal pace and then a faster one. A healthy wheel produces a steady stream of events in the direction you declared. Reversals inside a declared phase, long gaps in the middle of a continuous stroke, or a phase with far fewer events than its twin are the three patterns worth retesting. Confirm any of them in a second browser before deciding the hardware is at fault.