I found this the expensive way: by shipping a browser-based drift detector that had the failure mode backwards.

The symptom

The tool measured resting position. Plug in a controller, leave the sticks alone, sample axes over a rolling window, and report the offset from centre. Mild wear showed up exactly as expected, around 0.05 to 0.09. Badly worn controllers, the ones a user is actually worried about, came back as a clean 0.0 on every axis. Perfect health.

Not noise. Not a rounding artifact. A hard zero, every frame, for a stick you could watch drifting on screen in any native tool.

The mechanism

It is in device/gamepad/gamepad_pad_state_provider.cc. Line 23:

const float kMinAxisResetValue = 0.1f;

And the sanitization pass, roughly 130 lines down:

uint32_t full_axis_mask = (1 << pad->axes_length) - 1;
if (pad_state->axis_mask != full_axis_mask) {
  for (size_t axis = 0; axis < pad->axes_length; ++axis) {
    if (!(pad_state->axis_mask & 1 << axis)) {
      if (fabs(pad->axes[axis]) < kMinAxisResetValue) {
        pad_state->axis_mask |= 1 << axis;
      } else {
        pad->axes[axis] = 0.0f;
      }
    }
  }
}

Read the else branch carefully. Every axis starts life masked. Chromium will not expose its real value until it has personally observed that axis sitting below 0.1 at least once. Until then the value is not clamped, not smoothed, and not flagged. It is replaced with 0.0f.

The rationale in the source is a privacy one, and it is a good rationale. A controller with a worn potentiometer, or one with something leaning on a stick, streams input the user never produced. Browsers treat gamepad activity as a user gesture, so that phantom input could expose gamepad information to a page the user never interacted with. Requiring an at-rest reading before trusting an axis closes that hole.

So this is not a bug. It is anti-fingerprinting sanitization working exactly as designed. It just happens to be catastrophic for the one use case that cares about resting position.

The inverted failure mode

Line the numbers up and the shape of the problem becomes clear. Take a detector with a warning threshold at 0.05 and a failure threshold at 0.15, against Chromium's 0.1 mask:

A diagnostic built this way detects exactly the problems that do not matter and goes blind precisely as the problem becomes real. It does not degrade at the margin. It inverts.

Worse, it inverts silently. There is no error, no NaN, no console warning. You get a well-formed float that says the hardware is fine.

Why you cannot simply check for zero

The obvious patch is to treat 0.0 as suspicious. That does not work, because a genuinely centred healthy stick also reports 0.0. Masked and healthy are indistinguishable from a single sample. The API exposes no mask state.

The second instinct is to wait until the axis reads near centre, then start trusting it:

// WRONG
if (Math.abs(pad.axes[i]) < 0.08) trusted[i] = true;

This is worse than useless. A masked axis reports 0.0, and 0.0 passes that test on the very first frame. You have written a check that is satisfied by the exact condition it was supposed to detect.

The one signal that does prove the mask is gone

Go back to the else branch. While an axis is masked, any reading at or above 0.1 gets overwritten with zero. So a masked axis is incapable of reporting a large value.

Which gives you the inference:

If you have observed |axes[i]| > 0.6, that value survived sanitization. Therefore the mask for axis i is cleared, and everything it reports from now on is real.

A large reading is the proof. Not a small one. This is the part that is easy to get backwards, and getting it backwards is what produces a detector that looks rigorous and measures nothing.

Physically this is also why a full stick rotation fixes the problem. Rotating the stick through its full range takes each axis from one extreme to the other, and on the way it crosses through the centre, dipping under 0.1 even when the stick's resting position is offset by 0.3. The mask clears mid-rotation. This is why a controller that has been used for thirty seconds reports drift correctly, while one that was plugged in and immediately tested does not.

That last detail matters more than it sounds. The mask is sticky for the device's connection lifetime in the browser process, and it is shared across tabs and reloads. So it bites exactly one population: the user who plugs in a controller, goes straight to a testing page, and carefully leaves the sticks alone because that is what testing resting position sounds like it should involve. That is the entire audience for a drift test.

If your UI says "keep both sticks centred", you have written an instruction that guarantees the bug.

Detecting drift anyway

Track two facts per axis, and gate the verdict on them:

const SWEEP_HIGH = 0.6;  // proves the mask is cleared
const SWEEP_LOW  = 0.08; // proves we have seen a real release

const sweep = new Map();

function trackSweep(pad) {
  let axes = sweep.get(pad.index);
  if (!axes || axes.length !== pad.axes.length) {
    axes = Array.from(pad.axes, () => ({ high: false, low: false }));
    sweep.set(pad.index, axes);
  }
  for (let i = 0; i < pad.axes.length; i++) {
    const magnitude = Math.abs(pad.axes[i]);
    // Order matters: only count a low reading once we know values are real.
    if (magnitude > SWEEP_HIGH) axes[i].high = true;
    if (axes[i].high && magnitude < SWEEP_LOW) axes[i].low = true;
  }
  return axes;
}

function axisIsTrustworthy(axes, i) {
  return axes[i].high && axes[i].low;
}

The ordering in that loop is the whole fix. low is only allowed to latch after high has, because before high a low reading is worthless: it is probably the mask.

Then let the verdict be three-valued rather than two-valued:

function driftVerdict(pad, axes, i) {
  if (!axisIsTrustworthy(axes, i)) return 'unverified';
  const resting = Math.abs(pad.axes[i]);
  if (resting >= 0.15) return 'drift';
  if (resting >= 0.05) return 'mild';
  return 'ok';
}

unverified is not a cosmetic addition. It is the honest state, and without it the tool is forced to render a masked axis as healthy. Ask the user to rotate the stick fully and release it, and only then report.

One asymmetry worth building on deliberately: masking can only ever hide drift, never invent it. A non-zero reading has already survived sanitization. So a positive drift result is trustworthy immediately and should never be gated behind the sweep. Gate the all-clear, not the alarm.

Buttons have the same problem, and it is nastier

The button branch, immediately below the axis one, applies the same idea:

if (!pad->buttons[button].pressed) {
  pad_state->button_mask |= 1 << button;
} else {
  pad->buttons[button].pressed = false;
  pad->buttons[button].value = 0.0f;
}

A button must be seen released before it is trusted. So a button that is physically stuck down, one of the most common controller faults there is, is reported as never pressed, with an analog value of 0.0 to match. It does not appear as stuck. It appears as absent.

For a hardware test that is the worst possible rendering, because "this button never fires" and "this button is jammed on" call for completely different repairs, and the API collapses them into the same output. Track a released-observed bitmask per button and render anything unconfirmed as unverified rather than OK.

Testing this without a broken controller

You do not need worn hardware. You need a fake one, plus a simulation of the mask.

Replace navigator.getGamepads with a stub that returns a synthetic pad, then apply Chromium's own sanitization rules to your synthetic values before handing them over. Roughly forty lines reproduces the behaviour:

function maskedPad(rawAxes, state) {
  return rawAxes.map((v, i) => {
    if (state.cleared[i]) return v;
    if (Math.abs(v) < 0.1) { state.cleared[i] = true; return v; }
    return 0.0;
  });
}

Drive that with a scripted sequence: a pad whose true resting offset is 0.30, held still for two seconds, then rotated, then released. A correct detector reports unverified, then drift. An incorrect one reports ok for the entire run and never changes its mind.

Running our old implementation through that harness reproduced the failure on both attempts. The replacement passed all sixteen scripted cases. That gap, two versus sixteen, existed before either version touched real hardware, which is the argument for building the harness at all.

Two related limits, since they surface in the same place

Update rate is capped. device/gamepad/gamepad_provider.cc line 78 sets kPollingIntervalMilliseconds = 4, annotated in the source as roughly 250 Hz. A 1000 Hz controller and a 250 Hz controller are indistinguishable from JavaScript. Anything you measure in a browser is min(controller rate, browser delivery rate, your sampling rate), so calling the result a controller's polling rate is not accurate. Observed update rate, browser limited, is the honest label.

Gamepad.id has no standard format. On Chrome and Edge on Windows, every XInput device identifies as Xbox 360 Controller (XInput STANDARD GAMEPAD), with no vendor or product ID, which makes a Series X pad indistinguishable from a decade-old 360 pad. Firefox on Windows reports the string xinput and nothing else. Other platform and browser combinations do expose VID and PID, in at least three mutually incompatible formats, one of which uses unpadded hex. If you are doing per-model analysis, measure how often you can identify the model at all before trusting any of it.

The general lesson

The Gamepad API is not a sensor feed. It is a sanitized, privacy-filtered view of one, and the filter is tuned for games, where a stick that has never been touched genuinely should read zero. Diagnostics inherit assumptions that were never written for them.

Before you trust any browser input value, find out what the browser does to it first. In this case that is about twenty lines of C++, it is public, and reading it would have saved me a release.

Written by Taimoor Bamazai, founder of Elites Algorithm (Dublin, Ireland and Pakistan). Builder of JoyCheck and its privacy-first browser controller diagnostics.