Blog
CPS Test Not Working? Fixes for Clicks Not Registering
CPS test not counting your clicks? Fixes for pointer events, blocked right-click, keyboard input, embedded tests, touch issues and silent browser throttling.
A CPS test that won’t count clicks almost always fails the same way: the browser isn’t delivering the press events the tester is listening for — because of input mode confusion, prevented context menus, keyboard focus, browser throttling or a page embedded in an iframe. Every “broken” tester I’ve debugged for this site came down to one of five fixes. This page walks them in order, with the exact checks that identify yours in under a minute.
Fix 1: Check the input mode vs. what you’re pressing
The most common false “not working” is a mode mismatch. The tester has separate input modes — mouse, right-click, spacebar and keyboard. In right-click mode only the right button counts; in mouse mode the left button counts; a press on the wrong button simply does nothing, which feels like a broken tester. Set the mode to match what you’re actually mashing before changing anything else. If the mode selector is on the page, the fix is one click. This one mistake explains a surprising share of “the test ignores my clicks” reports — see the right-click testing guide and the mouse testing guide for how each mode is wired.
Fix 2: Unblock the context menu for right-click mode
Right-click tests set up against browsers’ built-in context menu, which eats the second button’s events in some browsers. The fix on this site (and most modern testers) is preventing the context menu inside the click zone so every right-button press registers. If a tester still shows a context menu when you right-click, its events are being intercepted — try focusing the test area first, then right-clicking. On macOS trackpads, remember right-click is often a two-finger tap, and some systems delay that event until the tap completes, which shortens your measurable clicks in right-click mode.
Fix 3: Keyboard mode needs focus
Spacebar and keyboard modes listen to key events on the page, and keyboard events only fire when the page (or a focused element) is listening. If clicking into the zone first is required and you’re typing while some other element holds focus — especially a button, input or select — the keystrokes go nowhere. The reliable pattern: click the click zone once to focus, then tap. A full-screen iframe embedding (see Fix 5) also needs that initial focus before keys register. If keys work everywhere else but not in the tester, a browser extension remapping shortcuts is the usual culprit — try the spacebar test in an incognito window to confirm.
Fix 4: Touch devices, scrolling and ghost taps
On phones and tablets, the tester’s tap zone distinguishes taps from scrolls by movement threshold — a finger that moves more than a few pixels while pressed is treated as a scroll, not a click, so dragging across the zone deliberately won’t count. That’s correct behavior: scroll-guarding is what lets mobile pages scroll normally without registering accidental “clicks”. If taps genuinely don’t register on touch, pull down to create a fresh page (throttled background pages can lag event delivery), and disable any aggressive ad-blocker that strips scripts. The mobile testing guide covers the phone-specific behavior in depth, including why tapping harder doesn’t make a touchscreen register more.
Fix 5: Embedded or throttled testers
Two silent killers round out the list. First, embedded testers: some sites embed the tester in an iframe, and iframes need user interaction before they can process certain input events — a banner or overlay on top of the frame will swallow every click without visibly blocking it (the overhead layer is invisible). Look for anything floating over the tester and dismiss it. Second, browser throttling: background tabs and battery-saver modes slow timers and event delivery, so a test running in a tab you switched away from will finish late and count low. Keep the tester in the foreground tab, ideally with the page fully loaded and no pending scripts, and retest — the accuracy explainer details how much environment moves the number.
The two-minute diagnostic
When a tester “doesn’t work,” run this order: switch the mode to mouse and click the left button in the zone (rules out mode confusion) → confirm the page has focus (click anywhere on the page once) → try incognito with extensions disabled (rules out blockers) → try the direct test page instead of an embedded copy (rules out iframe layers) → try a different browser device (rules out throttling). If clicks register on the main tester after all five, the tester itself was never broken — something in the environment was eating the events. And if a specific copy of the tester on another site won’t count, that site’s embedding is the problem, not your clicking — the same card that is embeddable with one line of code on this site is also, occasionally, embedded badly elsewhere.