Mouse Test
Mouse health check
{{ summaryLine }}
{{ summaryValue }}
{{ exportStatus }}
{{ reportText }}{{ exportStatus }}
| Button | Finding | Gap (ms) | Threshold (ms) | Time (ms) | Code | Copy |
|---|---|---|---|---|---|---|
| {{ row[0] }} | {{ row[1] }} | {{ number(row[2]) }} | {{ number(row[3]) }} | {{ number(row[4]) }} | {{ number(row[5]) }} |
{{ 'No possible faults observed in the captured input.' }}
{{ exportStatus }}
| Time (ms) | Delta Y | Delta X | Units | Mode code | Finding | Step | Copy |
|---|---|---|---|---|---|---|---|
| {{ number(row[0]) }} | {{ number(row[1]) }} | {{ number(row[2]) }} | {{ row[3] }} | {{ number(row[4]) }} | {{ row[5] }} | {{ row[6] }} |
{{ 'No wheel events recorded yet.' }}
{{ exportStatus }}
| Direction | Events | Reversals | Magnitude variations | Delivered delta | Units | Copy |
|---|---|---|---|---|---|---|
| {{ row[0] }} | {{ number(row[1]) }} | {{ number(row[2]) }} | {{ number(row[3]) }} | {{ number(row[4]) }} | {{ row[5] }} |
{{ exportStatus }}
Chart unavailable. The report retains the interval distribution.
Similar tools
- Keyboard Test Check which keyboard keys register and investigate repeated or missing presses, with local event analysis and a report you can share.
- CPS Test Measure clicks per second in a timed browser trial, compare pace and consistency, and filter near-duplicate presses when checking switch bounce.
- Gamepad Test Test your gamepad for stick drift, missed buttons and trigger range, with suggested deadzones and a local report of the recorded evidence.
- Touch Screen Test Check your touchscreen for missed or unwanted touches in your browser and save an observation report for purchase or repair discussions.
A mouse that registers a double click when you intended a single click, or lets go halfway through a drag, needs a check of what each control actually delivers. Slow, deliberate actions make unwanted repeats easier to distinguish from intentional rapid clicking. Reproducing the same symptom also gives a seller or repairer more useful evidence than a general report that the mouse feels unreliable.
In a mechanical button switch, moving electrical contacts can briefly make and break contact before settling. This is contact bounce. Debouncing filters those brief changes so one physical action produces one intended input. If extra transitions reach the computer, a single click can appear as several clicks. An interruption while the button should remain pressed can break a drag or text selection. Ordinary contact bounce is not itself proof of wear, and a browser cannot inspect the contacts or identify the cause of an unexpected release.
Different actions expose different problems, so a working primary button does not establish that the rest of the mouse behaves correctly.
- Individual clicks check left, right, middle, back and forward where those controls are present. Pressing the wheel is a separate action from rolling it.
- Continuous holds check whether a button remains down during movement. A drag that ends before the finger lifts is a different symptom from an extra click after release.
- Steady scrolling checks both directions and wheel tilt, if fitted. Missing movement or a brief movement in the opposite direction deserves repetition with the wheel turning steadily.
A tactile wheel notch is a physical step felt by the finger. A browser wheel event is a software report of scrolling, expressed in pixels, lines or pages. Smooth scrolling, acceleration and wheels that spin without distinct notches prevent a reliable one-event-per-notch assumption. A whole session scrolling in the opposite direction may reflect a scrolling preference; an occasional reversal during a steady roll is a different observation.
Polling rate describes how frequently mouse information can be requested or reported to the computer, expressed in hertz, or times per second. A browser estimates delivery timing from movement timestamps. It may combine several updates into one event, sometimes exposing the earlier updates as coalesced events. That estimate cannot establish the mouse's configured hardware rate or the delay from a physical click to a visible response. Stillness can produce no useful movement samples without indicating a fault.
The operating system and mouse software also decide what reaches an application. A left-handed button swap changes logical button roles, while a side button may be assigned a keyboard shortcut or browser navigation. Other buttons may trigger shortcuts or change settings without delivering a standard mouse-button event. An absent browser event therefore needs a settings check before it becomes evidence against a physical button.
Start fault isolation with cleaning according to the manufacturer's instructions, connection checks and button or scroll settings. A problem confined to one application calls for a settings check. Repeated failure of the same physical control on another computer makes hardware trouble more plausible. Persistent button trouble may justify a switch repair assessment or a warranty enquiry. For a used purchase, a clean session supports the observed behavior only; it cannot establish remaining switch life or exclude intermittent faults.
How to Use This Tool:
Use a physical USB or Bluetooth mouse and keep the pointer in the pad during each check. On a phone or tablet, connect a mouse first. Touch and pen input do not count, and a trackpad can resemble mouse input without being suitable for this diagnosis.
- Mark only controls your mouse physically lacks under Buttons absent on my mouse. Leave a present but unresponsive button included so its missing coverage remains visible.
- Choose any needed Advanced settings before starting. Blank numeric fields use a 50 ms fault threshold, a 5,000 ms polling window and 10 counted wheel notches per direction. Optional model and notes give the report context.
If Check Advanced settings appears, correct the indicated value or clear its field to restore the default. Recorded evidence is retained while the setting is invalid.
- Select Start and follow each named button's slow-click check. Make five separate clicks with about a second between presses, then use Next step. Gray means untested, green means registered and blue means currently held.
- Perform each guided hold by pressing the named button, moving for a few seconds and releasing deliberately. Use Repeat step when an action was unclear. Skip step moves on without marking that check complete.
- Roll the requested number of physical notches down, then up, and confirm only a count you actually made. For a smooth wheel without countable notches, skip the counted check and inspect the delivered scrolling evidence instead.
- Move continuously in fast circles during the polling step, then select Finish after the displayed sampling window. Stop can retain a partial session at any point. Losing focus or hiding the tab pauses capture; Resume keeps the existing observations.
- Review the summary and Defect report, then repeat any unexpected behavior under the same settings. Copy or download the report before Start again or Reset replaces the evidence. Record the physical action and connection in the notes when preparing evidence for a seller or repairer.
Interpreting Results:
Buttons tested counts included logical buttons with an observed press. It does not confirm that every requested click or hold was performed. Step completion follows your confirmation, and a short uneventful run cannot rule out an intermittent problem.
- Repeat flagged button input means a release was followed by another press below the selected threshold. Repeat deliberately slow clicks or a steady hold. Intentional rapid clicking can produce the same flag. An unwanted release without a quick re-press may receive no hold-drop flag, so compare recorded releases with what your finger actually did.
- Review wheel delivery means a direction or magnitude rule was triggered, or a confirmed notch count produced no wheel events. Repeat a steady roll and check scrolling preferences before inferring a damaged wheel.
- Review hold at Stop preserves the fact that a button was still held when capture stopped. Release deliberately in another check; stopping while holding is not a diagnosed fault.
- Coverage incomplete means included buttons, guided checks or movement samples remain incomplete. Check mappings before excluding a silent button.
- No flagged input observed means the required coverage was reached without these flags. It is evidence about this session, not a hardware certification or a guarantee for a used purchase.
Treat the polling value as a browser delivery estimate. A lower bound result has been capped by browser frame timing, and the nearest common reference is only a comparison label. Neither establishes hardware polling rate or click latency.
For a repeatable symptom, change one condition at a time. Check button assignments, reconnect the mouse or receiver directly, and compare another application or computer. Before cleaning, disconnect or switch off the mouse and follow its manufacturer's guidance; avoid liquid entering the device.
A symptom that remains with the same physical button across those checks strengthens the case for hardware service. Ask the seller or manufacturer about warranty service before opening a covered mouse. Otherwise, a repairer can assess whether a compatible switch replacement is appropriate. Wheel-only symptoms need their own inspection. The report documents observations and does not determine warranty eligibility.
Technical Details:
Button diagnosis depends on the order of presses and releases. The short interval used for a chatter flag runs from a release to the next press of the same button. It is different from the duration of a hold, the time between two press beginnings or an operating system's double-click setting.
Formula Core: button timing
The release-to-press gap is calculated from two browser event timestamps in milliseconds.
Here, g is the gap and T is the selected fault threshold, both in milliseconds. A release becomes eligible for this comparison only after an observed press of that button in the same uninterrupted step attempt. These are screening rules chosen for this test, not manufacturer switch specifications.
| Observation | Condition | Meaning |
|---|---|---|
| Possible chatter | 0 ≤ g < T outside that button's matching hold step | A rapid release and re-press to investigate. |
| Possible hold-drop | 0 ≤ g < T during that button's matching hold step | The same short-gap pattern during an intended hold. |
| No short-gap flag | g ≥ T | Equality does not qualify. The observed presses and releases remain recorded. |
| Release without a rapid re-press | No qualifying following press | No automatic hold-drop flag, even if the release was unwanted. |
A button already held when it enters the pad may appear held without receiving a counted press or tested credit. Its later delivered release can still be counted. Pressing another button while one is held is also handled as a separate logical transition. New steps, pauses and stopping clear the short-gap pairing so unrelated actions are not joined across those boundaries. Excluding a button changes guided coverage without deleting its recorded input or possible faults.
Lowering T reduces which short gaps qualify; raising it includes more deliberate fast clicks. The standard 50 ms value is a heuristic for slow, isolated clicks. Changing it affects classification, not the mouse's physical debouncing or operating-system settings.
Wheel direction and magnitude rules
A wheel delta is the signed scroll amount delivered by the browser. Positive vertical values are labelled Down and negative values Up; positive horizontal values are Tilt right and negative values Tilt left. These labels describe the delivered sign, which scrolling preferences can reverse relative to the physical gesture.
Pixels, lines and pages remain separate units. For each axis, nonzero deltas are compared only within the same unit and the same step attempt. This prevents a change of unit or a deliberate change between guided directions from being treated as a reversal within one roll.
| Rule | Exact condition | Boundary or limit |
|---|---|---|
| Reversal | Consecutive nonzero deltas have opposite signs and are at most 250 ms apart. | Exactly 250 ms qualifies; a longer gap does not. |
| Magnitude variation | An absolute delta differs from the attempt's median absolute delta by more than 50% of that median. | Exactly 50% does not qualify. This rule has no 250 ms time limit. |
| Counted roll with no delivery | A positive physical-notch count is confirmed, but the attempt contains zero wheel events. | Flagged for repetition; interception remains possible. |
Magnitude variation compares the size of a scroll change with the typical size in that attempt, ignoring its sign.
Here, d is one nonzero delta and m is the median absolute delta for the same axis, unit and attempt. Both use the delivered unit. A direction change and a magnitude change can occur independently, and neither heuristic proves a physical fault.
Nonzero wheel-event counts are not expected to equal counted physical notches. The test cannot locate an individual missed notch from those totals. Direction totals sum signed deltas separately for each unit. Direction-wide event and flag counts repeat if that direction has several unit rows, so those repeated counts must not be added together. One event with both horizontal and vertical deltas can contribute to two directions.
Formula Core: polling estimate
Movement updates may reach the browser individually or in groups. Coalesced events expose available updates that were combined for delivery. Raw updates can arrive more promptly than ordinary movement events, but they still pass through the browser and may themselves be grouped.
- Keep moving samples from the guided polling attempt's start through the configured endpoint, including a sample exactly at that endpoint.
- Use the first available timing source in this order: coalesced samples from raw updates, coalesced samples from ordinary movement, raw-update timestamps, then ordinary movement-event timestamps. Use only that source within each attempt to avoid duplicate observations.
- Sort distinct timestamps within each attempt. Retain positive consecutive gaps through 50 ms inclusive and exclude gaps above 50 ms as rests. Do not create intervals across separate attempts.
- Pool the retained intervals and take their median. For an even number of intervals, average the two middle values after sorting.
Dividing the milliseconds in one second by the median interval gives the uncapped browser delivery estimate in hertz.
The movement median is in milliseconds and R is in hertz. Twenty-one distinct moving timestamps spaced 8 ms apart give 20 intervals, an 8 ms median and an uncapped estimate of 125 Hz. If every contributing attempt uses coalesced or raw timing, that is also the reported estimate; ordinary movement-event timing requires the additional cap below.
If any polling attempt relies on ordinary movement-event timestamps, the fallback is labelled a lower bound and capped by the observed browser frame cadence. The reported estimate is the smaller of the two rates.
The frame median is the median positive interval between observed browser animation frames, keeping intervals through 50 ms, in milliseconds. If that cadence is unavailable, the fallback's reported estimate is unavailable. Neither the cap nor its lower-bound label establishes a calibrated hardware rate or a hardware ceiling.
The nearest common reference is chosen by the smallest difference in interval, not the smallest difference in hertz. An exact tie selects the lower reference rate. These reference values do not read or identify the mouse's negotiated USB configuration.
| Reference rate (Hz) | Interval (ms) |
|---|---|
| 125 | 8 |
| 250 | 4 |
| 500 | 2 |
| 1,000 | 1 |
| 2,000 | 0.5 |
| 4,000 | 0.25 |
| 8,000 | 0.125 |
The interval histogram uses 16 equally wide bins across the retained interval range. Each includes its lower edge and excludes its upper edge, except the last bin includes both. Identical intervals receive a display range extending 20% below and above their value. The histogram shows delivery variation; it is not a distribution of click latency.
Browser scheduling and privacy-related timestamp rounding limit the estimate even when fractional milliseconds are displayed. The smallest positive retained interval, reported as the observed timer increment, is only a timing-granularity clue. It is not calibrated clock resolution. For comparisons, keep the browser, connection, mouse settings and movement pattern consistent, and check whether the acquisition method changed.
Settings, completion and precision
These bounds define valid settings. Clearing a numeric override restores its stated default.
| Setting | Default | Accepted range |
|---|---|---|
| Fault threshold | 50 ms | 1 to 500 ms inclusive; decimals accepted. |
| Polling sample window | 5,000 ms | 1,000 to 15,000 ms inclusive; whole numbers. |
| Wheel test length | 10 notches | 1 to 100 notches inclusive; whole numbers. |
Complete guided coverage requires at least one included button, a recorded press for every included button, confirmation of every required guided check and at least 20 retained movement intervals. An estimate can appear with fewer intervals. Possible button faults take precedence in the summary, followed by wheel concerns and a held button at Stop; complete coverage without those findings yields No flagged input observed.
Threshold comparisons use retained numeric values before display rounding. Noninteger values in the tables and text report are shown to at most eight significant digits; a rounded boundary value can therefore need a closer look. Session times run from the first Start and include pauses, while short-gap comparisons and movement intervals remain confined to uninterrupted attempts.
Privacy and Browser Limits:
The mouse test processes observations in the current tab and requests no special device-access permission. Captured observations, absent-button choices, model and notes stay in the tab without being uploaded or automatically saved for later visits. Copying or downloading a report deliberately preserves the reported evidence outside that temporary session. Table CSV, DOCX and row copies retain the stored numeric values. Only the three numeric Advanced overrides enter the settings URL. The report includes browser and platform information plus any model and notes you supply, so review it before sharing. Loading the page or chart can still require network requests for display resources.
- Recording starts only after Start and listens to the pad. Pointer capture can also deliver a release after the pointer leaves the pad. If capture is unavailable, keep releases inside the pad.
- The pad suppresses right-click menus, middle-button defaults and page scrolling from the wheel. Back and Forward suppression was verified in Chromium; Firefox and Safari/WebKit remain unverified. Browser settings, extensions or remapping can still cause navigation. Save other work before testing side buttons.
- Access to coalesced events and raw updates depends on browser support and a secure context such as HTTPS. Availability does not guarantee that those samples were supplied during a particular attempt.
- A session accepts at most 12,000 event records, with at most 256 coalesced samples per delivered event and 100,000 overall. Recording stops before those bounds are exceeded, retaining prior observations. Preserve the report before beginning another session.
- Settings remain fixed during active capture; edits take effect when capture stops or pauses and can reclassify retained evidence. Reset also clears model and notes, but keeps numeric overrides and absent-button choices. Start again keeps that optional context while replacing the observations.
Worked Examples:
A flag changes while the evidence stays the same
During one uninterrupted left-button slow-click attempt, a press is recorded at 900 ms, a release at 1,000 ms, another press at 1,012 ms and a release at 1,100 ms. The 12 ms release-to-press gap produces one Possible chatter finding at the default 50 ms threshold, with two presses and two releases. After Stop, changing Fault threshold to 12 ms removes that flag because equality does not qualify. The counts and 12 ms shortest gap remain. A lower flag count after changing the threshold is not evidence that the mouse has been repaired.
The nearest reference exceeds the reported estimate
Suppose ordinary movement events give a median interval of 2 ms while observed browser frame intervals have a median of 16 ms. The uncapped browser estimate is 500 Hz, but the fallback cap produces 62.5 Hz. Its effective interval is 16 ms, so the nearest listed reference is 125 Hz, corresponding to 8 ms. Read 62.5 Hz as the capped browser estimate and 125 Hz as a comparison reference. Neither number establishes the mouse's hardware configuration; compare another supported timing method before drawing conclusions about the device.
References:
- Pointer Events Level 4, Working Draft, W3C, 8 October 2026.
- Device Class Definition for Human Interface Devices, Version 1.11, USB Implementers Forum, 2001.
- Basic Switches: Explanation of Terms, OMRON.
- Debounce a Switch, Texas Instruments, October 2020.
- MouseEvent: button property, MDN Web Docs.
- WheelEvent: deltaMode property, MDN Web Docs, 13 February 2026.
- Event: timeStamp property, MDN Web Docs, 1 September 2026.
- Keyboard/Mice: Buttons or keys do not work correctly, Logitech Support.
- Scroll wheel stuck or does not respond, Logitech Support.
- Cleaning your Logitech device, Logitech Support.