A reasonable worry before you trust any browser input test: does the browser itself change what gets recorded? If Chrome, Safari and Firefox each reported your clicks differently, a result would say more about the browser than the device. So we tested it directly — the same clicks, the same scroll, and the same keys, run through all three browsers on one Mac, reading the tool's own output each time.
The short answer for this setup: they matched. Same scroll unit, same key codes, same short-interval count. Below is the verbatim data, and — just as important — the one difference a trackpad cannot rule in or out.
The setup (stated so you can repeat it)
- Operating system: macOS 15.7.7, one machine, built-in trackpad.
- Chrome 152.0.7977.83 · Safari 18.6 · Firefox 155.0.1.
- Input driven by an automation tool (events reached the page as trusted events); results read from the tool's saved report.
Scroll: same unit, different distance
Each browser scrolled down for six wheel events with “down” as the intended direction. The tool keeps pixel, line and page totals separate because engines can report them differently. Here they did not — all three reported pixels:
| Browser | Wheel events | Opposite-direction | Units (verbatim) |
|---|---|---|---|
| Chrome 152 | 6 | 0 | {"px": 1392} |
| Safari 18.6 | 6 | 0 | {"px": 1458} |
| Firefox 155 | 6 | 0 | {"px": 1308} |
The pixel totals differ (1392 / 1458 / 1308), but the scroll amount was not controlled between browsers, so that difference cannot be attributed to the engine — it could be the scroll distance, the engine, or both, and this run does not separate them. What it does establish is the unit type: all three delivered pixel-mode wheel deltas, and none recorded an opposite-direction event. A controlled equal-distance capture is on the pending list to compare magnitudes properly.
Keyboard: identical codes
Pressing A, B, a Shift combination and a down arrow produced the same recorded codes in every browser:
KeyA: 2/2, KeyB: 1/1, ShiftLeft: 1/1, ArrowDown: 1/1No engine relabeled a key, dropped the modifier, or reported a different code. The keyboard check saw the same events in Chrome, Safari and Firefox.
Double-click: same short-interval count
Six deliberate, separated left-clicks at an 80 ms review threshold produced 0 of 5 short intervals in all three browsers — consistent with clicking that was not fast enough to trip the filter, and consistent across engines. (For what that threshold does, see how the review threshold changes what gets flagged.)
What we could not test — and won't claim
There is one well-known place engines can differ: a mouse with a notched scroll wheel. Some browsers (historically Firefox) can report those notches as line units rather than pixels. We tested on a trackpad, whose smooth scrolling normalizes to pixels — so this run cannot confirm or deny that difference. We are not going to claim a divergence we did not observe. If you use a notched wheel, your scroll check report may show a different unit, and that would be expected.
Single-session captures on one macOS machine with a trackpad; input was driver-dispatched, so this documents engine event reporting, not a physical device. A small number of runs describes only those runs. The honest takeaway: on this setup the three engines agreed, and the tool records enough (browser, OS, units, codes) for you to check your own. The raw numbers are in the open double-click input behavior dataset.