desktest.net
guide

Mouse Test Guide

A reference for the desktest.net Mouse Test. Covers how it reads buttons, the scroll wheel, and pointer movement, how to read the verdict, and what to do about stuck buttons, dead scroll wheels, and low polling rate.

Open the Mouse Test ->

What does the Mouse Test check?

The tool drives the browser's PointerEvent API: pointerdown, pointerup, pointermove, wheel, and contextmenu listeners keyed off PointerEvent.button so each physical button maps to a stable index. No plugin, no extension, no upload. Works on Chrome, Edge, Firefox, and Safari. The three steps run in order:

  1. Pointer Events API is available. Feature-detects window.PointerEvent and reads the pointer type through matchMedia('(pointer: fine)') and '(pointer: coarse)' so the report notes whether a precise pointer (mouse, trackpad) or a coarse one (touch) is primary. It also notes whether the page is inside an iframe, which can swallow pointer capture.
  2. Every button registers. Five regions: Left (index 0, main button), Middle (1, the scroll-wheel click), Right (2, context menu), Back (3), and Forward (4). Press each button and its region turns green. Right-click's context menu is suppressed with preventDefault() during the test so the OS menu does not cover the page. If a button fires pointerdown but no pointerup within 2 seconds, it is flagged stuck and turns red.
  3. Scroll and motion work. Scroll down at least 3 notches, scroll up at least 3, and optionally tilt the wheel sideways (horizontal scroll). Then move the pointer continuously over the pad for 3 seconds. The tool counts wheel events per direction and estimates the pointer's sample rate (events per second) over the movement window.

When should I run this?

Reading the results

The button map lights each region green on a clean press. Back and forward are marked optional; a basic 3-button mouse never lights them and that is not a failure. A region that receives pointerdown without a pointerup within 2 seconds turns red and is flagged stuck.

The motion panel shows scroll down and scroll up counts (green once each reaches 3), horizontal scroll events (labelled "tilt wheel detected" or "none, normal for most mice"), the estimated polling rate in events per second (green at 100 or above), and the number of movement samples collected.

Each step row carries a status badge: Pending (grey), Running (yellow), Pass (green), Partial (yellow), or Fail (red). A partial means the essentials registered but coverage was incomplete, for example only three of five buttons, or scroll in one direction only. On fail or partial the row expands with the diagnosis and a numbered checklist. The verdict panel at the top names the most likely cause and a recommended next step.

Copy Diagnostic Report copies a plain-text report: browser user-agent, platform, pointer type, per-button results, any stuck buttons, scroll counts per direction, the polling-rate estimate, movement-sample count, and the diagnosis tag from each step. Paste it into a ticket.

Common failures and fixes

The tool produces a named diagnosis for every failure path. Each maps to a fix. In step order:

pointer-api-unsupported: the Pointer Events API is missing

The browser does not expose window.PointerEvent. Every desktop browser from the last decade supports it, so this almost always means a very old browser or a locked-down embedded shell.

  1. Update the browser. Pointer Events shipped in Chrome 55, Edge, Firefox 59, and Safari 13.
  2. If you opened the test through a kiosk wrapper, an Electron host, or an in-app browser (a chat client's preview pane), open it in a real browser tab instead.

no-buttons: nothing registered

No button fired during the test. Usually a focus or interception problem rather than dead hardware.

  1. Rerun and make sure the cursor is over the page before you click.
  2. Click each button in turn: left, middle, right, and the two side buttons if present.
  3. Accessibility software or a screen-reader pass-through can intercept clicks. Disable it and retry.
  4. Test in a second browser. If buttons work there, the original browser profile or an extension is at fault.

stuck-button: pointerdown without pointerup

A button stayed asserted for over 2 seconds without a release. Most often a failing microswitch, but check software first.

  1. Windows ClickLock. Mouse settings has a ClickLock option that latches the button after a brief hold, which looks exactly like a stuck button. Confirm ClickLock is off, then retry.
  2. Unplug the mouse, blow out the affected switch with compressed air, and replug.
  3. If it still sticks, the microswitch is failing. Many mice can be resoldered with a new Omron or Kailh switch; inexpensive mice are not worth the effort.

missing-button: left, middle, or right did not press

One of the three core buttons never registered. Isolate hardware from configuration.

  1. Try the button in another app: any text field for left-click, a browser for right-click. If it works there, the issue is this page's focus, not the mouse.
  2. Windows: check Settings -> Bluetooth and devices -> Mouse for a swapped primary button. Left-handed mode swaps left and right.
  3. macOS: check System Settings -> Mouse -> Secondary click. A disabled secondary click suppresses right-click entirely.
  4. If a single button is dead in every app, the microswitch is failing. Swap mice to confirm.

3-button-only: side buttons did not register (partial)

Left, middle, and right all worked; back and forward did not. For a basic 3-button mouse this is normal and reports as a partial, not a fail. If your mouse does have side buttons:

  1. Check the manufacturer driver (Logitech G Hub or Options+, Razer Synapse, Microsoft Mouse and Keyboard Center) for a software remap that swallows the buttons or binds them to a macro instead of Back/Forward.
  2. Some browsers consume back and forward as navigation before the page sees them. If the side buttons work in a desktop app but not here, the hardware is fine.

no-scroll: the wheel did not register

No wheel events fired during the test.

  1. Confirm the cursor was over the scrollable box before you scrolled.
  2. If the wheel turns physically but no event fires, the encoder inside the wheel has failed. On older mice this is the most common end-of-life symptom.
  3. On a laptop, two-finger scroll on a precision touchpad also fires wheel events. If the mouse fails but the touchpad scrolls, the fault is the mouse, not the browser.

low-polling-rate: fewer than 100 samples per second

The pointer reported under 100 movement samples per second across the 3-second window, where the browser could measure the true device rate (see Behind the scenes; this verdict is suppressed on browsers that cannot). A healthy mouse clears 100 easily; gaming mice report 1000 or more.

  1. Wireless battery. Low battery is the number-one cause of degraded polling. Replace or recharge first.
  2. USB 3.0 interference. USB 3 ports radiate noise in the 2.4 GHz band that starves wireless receivers. Move the dongle to a USB 2.0 port, or onto a short extension cable away from USB 3 ports and monitors.
  3. Wired mice: try a port directly on the PC, bypassing any USB hub or KVM.
  4. Update the mouse driver from the manufacturer.

partial-motion: not every prompt was completed

Scroll in a direction stayed below 3, or the movement pad never received a sample.

  1. Rerun and complete each prompt: scroll down at least 3 notches, scroll up at least 3, then move the pointer continuously over the pad for the full 3 seconds.
  2. If you cannot fill a scroll meter no matter how hard you try, that direction is dead. The encoder or its wiring has likely failed.

For IT admins

Mouse behavior is governed at three layers: hardware (the mouse and its receiver), OS (driver, accessibility, button map), and per-app (browser, vendor software, remote-session client). The test sees the last layer's view, but the failure pattern points at the layer to fix.

ClickLock and primary-button swap. Both live under HKCU\Control Panel\Mouse (ClickLock and SwapMouseButtons). On shared workstations, baseline the image with ClickLock off and the primary button set to left, and confirm no login script or user tool is flipping them. A latched ClickLock reads as a stuck button in every app, not just this one.

Vendor driver software. Logitech G Hub and Options+, Razer Synapse, and the Microsoft Mouse and Keyboard Center can remap buttons, bind side buttons to macros, and change pointer behavior per application. On a managed fleet, standardize whether that software is present at all; a per-app profile that swallows a button is invisible until someone runs a test like this.

Wireless placement. The USB 3.0 2.4 GHz interference problem is real and well documented by Intel. For 2.4 GHz wireless mice, put the receiver on a USB 2.0 port or a short extension away from USB 3 ports, external SSDs, and monitors. Bluetooth mice avoid the dongle but still suffer near a congested 2.4 GHz band.

KVMs, hubs, and remote sessions. Unpowered USB hubs and cheap KVM switches drop pointermove bursts and degrade polling; test the mouse plugged directly into the PC to confirm. In RDP, Citrix, or VDI, the remote client delivers pointer events at its own rate, so run this diagnostic on the physical endpoint, not inside the session, when you need to judge the hardware.

Double-click-on-single-click. A worn microswitch that has lost its debounce fires two clicks from one press. This is a common late-life failure on Logitech and Razer mice. The 2-second stuck-button check here does not catch a fast double-fire, so if users report phantom double-clicks, treat it as a failing switch even when this test passes.

Behind the scenes

The tool uses Pointer Events rather than the older Mouse Events because Pointer Events unify mouse, pen, and touch, expose a stable pointerId, and, importantly here, carry a coalesced-event history. PointerEvent.button gives the physical button index (0 left, 1 middle, 2 right, 3 back, 4 forward), which is what a hardware test wants.

Right-click is handled by calling preventDefault() on contextmenu for the duration of the test so the OS menu does not cover the page; outside the test the menu behaves normally.

Stuck-button detection is a 2-second timer started on pointerdown and cleared on pointerup. If the timer fires first, the button is flagged stuck and turns red.

The polling-rate figure needs a caveat. Browsers coalesce pointermove down to the animation frame, so a naive listener sees only about 60 to 120 events per second even on a 1000 Hz mouse. Where the browser supports PointerEvent.getCoalescedEvents() (Chromium and Firefox), the tool expands each event into the raw device samples the browser buffered between frames, recovering the true device rate. Where it is not supported (older Safari), the number is shown for interest but the low-polling verdict is suppressed so the test never fails a mouse on a browser limitation.

Nothing leaves the browser tab. No pointer data is logged to a server, no telemetry beacon is fired, no analytics. The report is built on Copy from in-memory state, and the page discards everything on reload. Open DevTools, Network tab, and confirm: no outbound requests while the test runs.