A mouse scroll test on iPhone verifies whether the wheel events from an external mouse or trackpad reach the browser as expected, and the Mouse Scroll Test shows exactly which directions arrive by counting up, down, left, right, and zero-delta events on the page. You point at a dashed test area, scroll your input device, and watch the total events, directional buckets, latest delta pair, and signed cumulative X and Y values update in real time. This matters on iPhone because Apple's iOS and iPadOS route external pointing devices through their own accessibility and pointer stack, and a wheel event that feels normal on a desktop can arrive with a different magnitude, a different direction, or no event at all in Safari. The tool runs entirely in the current tab, so gestures are not uploaded, history is not saved across sessions, and a Reset button clears everything back to zero. That narrow, transparent contract makes it the fastest way to answer a simple question: does this device, this browser, and this input combination deliver wheel events in all four directions?
Connect Your External Mouse or Trackpad to the iPhone First
Before any scroll test can produce a useful result, the iPhone needs to actually see the input device. iOS and iPadOS support external pointing devices, including Bluetooth mice and trackpads such as the Magic Mouse and Magic Trackpad, through the accessibility and pointer stack, and the way those devices are connected changes how their wheel or scroll surface is exposed to Safari.
The most common route is through the iOS accessibility and pointer settings, where you can pair a Bluetooth mouse or trackpad. Some users connect through a Lightning or USB adapter. Whichever route you use, take a moment to verify the pointer follows your finger and that scrolling behaves at all in a regular webpage before opening the test tool. If the pointer does not move, the test area will not receive any wheel events and every counter will stay at zero, which looks identical to a real missing direction.
Open the Mouse Scroll Test in Safari, let it load fully, and rotate the iPhone into the orientation you actually plan to use. The orientation matters because Safari's viewport and pointer behavior change between portrait and landscape, and you want the test to match your real working setup rather than a configuration you will never run.
Run the Mouse Scroll Test on Your iPhone
This is the practical sequence that gives a clean answer for the four cardinal directions and the zero case on an iPhone.
- Place the pointer inside the dashed test area. The area intercepts wheel events so the page does not scroll itself and the pointer stays put while you compare directions.
- Spin the wheel up several times using short, deliberate movements. Watch the directional bucket for up change and the total event count tick up on each notch.
- Spin the wheel down several times in the same controlled way. Confirm the down bucket increments and the latest delta pair shows negative vertical values on screen.
- If your device exposes a tilt wheel or horizontal scroll surface, swipe left and right and confirm the left and right buckets increase. A traditional vertical wheel will usually leave these buckets empty, which is expected and not a failure.
- Trigger a zero-delta event, if your device or driver can produce one, and confirm the none bucket increments instead of any cardinal direction. Zero events are preserved in their own bucket rather than silently dropped.
- Read the latest delta pair, the signed cumulative X and Y values, and the directional counts side by side. Compare each bucket label with the gesture you just made before moving on.
- Tap Reset test to clear every count and total back to zero, then repeat the sequence slowly and quickly to compare behavior at different speeds on the same device.
If you want a deeper read on what each field represents and how to interpret unusual values, the Mouse Scroll Test accuracy guide walks through the same fields and explains why a "normal" delta is not a fixed number across devices and browsers.
How the Tool Decides Which Bucket Each Event Enters
The classification rule is deliberately transparent so each event lands in exactly one visible bucket without implying the gesture only moved on one axis. The rule is shown in the table below.
| Condition on the delta pair | Bucket chosen |
|---|---|
| deltaX = 0 and deltaY = 0 | none |
| |deltaY| is greater than |deltaX| | up if deltaY is positive, down if deltaY is negative |
| |deltaX| is greater than |deltaY| | left if deltaX is negative, right if deltaX is positive |
| |deltaX| equals |deltaY| and both nonzero | vertical wins by tie rule: up or down from the sign of deltaY |
This rule means a diagonal trackpad gesture with equal horizontal and vertical components is logged as a vertical event, not as a missing horizontal one. The raw delta values are still preserved in the latest pair and the cumulative sums, so the diagonal motion is not lost, it is just summarized under one label.
The test area also handles two practical details that often confuse first-time users on iPhone. It suppresses the page's normal scroll only for events that arrive inside the dashed zone, so the rest of the page scrolls normally if you scroll outside the area. And while the area can receive keyboard focus for a visible outline, keyboard arrow keys are not treated as wheel input, so pressing them will not increment any bucket.
Worked Example: Three Events on an iPhone Safari Run
Imagine three wheel events arrive in a single session on your iPhone. The raw pairs, the classification, and the running sums look like the steps below. The arithmetic is written out so you can follow each update, and the totals are computed directly from the values shown, not from any external calculation.
Start state before any events: total = 0, up = 0, down = 0, left = 0, right = 0, none = 0, cumulative X = 0, cumulative Y = 0.
Event 1: deltaX = 0, deltaY = -120. Rule check: |deltaY| = 120 is greater than |deltaX| = 0, so vertical wins and the sign is negative, giving bucket down. Updated values: total = 0 + 1 = 1, down = 0 + 1 = 1, cumulative X = 0 + 0 = 0, cumulative Y = 0 + (-120) = -120. Latest pair shown on screen: (0, -120).
Event 2: deltaX = 80, deltaY = 0. Rule check: |deltaX| = 80 is greater than |deltaY| = 0, so horizontal wins and the sign is positive, giving bucket right. Updated values: total = 1 + 1 = 2, right = 0 + 1 = 1, cumulative X = 0 + 80 = 80, cumulative Y = -120 + 0 = -120. Latest pair shown on screen: (80, 0).
Event 3: deltaX = -80, deltaY = 0. Rule check: |deltaX| = 80 is greater than |deltaY| = 0, so horizontal wins and the sign is negative, giving bucket left. Updated values: total = 2 + 1 = 3, left = 0 + 1 = 1, cumulative X = 80 + (-80) = 0, cumulative Y = -120 + 0 = -120. Latest pair shown on screen: (-80, 0).
Final reading after the three events, derived from the arithmetic above: total events = 3, down = 1, right = 1, left = 1, up = 0, none = 0, latest pair = (-80, 0), cumulative X = 0, cumulative Y = -120. The cumulative X settled at zero even though one right and one left event both fired, which is exactly the signed-sum behavior the FAQ describes. If you want the exact numbers from your own iPhone session, the tool always shows them live; this example only illustrates the math.
Why iPhone Deltas Often Look Different From Desktop Numbers
Raw deltas on iPhone are not calibrated physical distance. They are whatever the browser chose to report for that wheel event, which depends on the input device, the iOS version, Safari's event delivery, and any accessibility or assistive software in the path. The same scroll motion on a Magic Mouse connected to an iPhone can produce a different magnitude than the same Magic Mouse connected to a Mac, and the test does not normalize that away.
Three specific behaviors are worth knowing on iPhone. First, Safari may combine, smooth, accelerate, or suppress wheel events before the page sees them, so a fast flick can produce fewer events with larger magnitudes than a slow, deliberate spin. Second, touch-based scrolling on the screen itself does not generate wheel events, so a finger swipe will not move any counter even though the page scrolls. Third, a tilt wheel or a horizontal scroll surface may map to different deltaX magnitudes depending on the driver, so left and right buckets can fill up with very different numbers than up and down on the same device.
The tool also rejects non-finite synthetic deltas and guards counter overflow, so an unusual event from a remote desktop session or a third-party driver will not corrupt the totals. The reliable contract is narrow: record finite browser wheel deltas delivered to the zone, apply the disclosed dominant-axis classification, keep transparent counts and signed sums, and never present those browser values as calibrated hardware measurements.
When a Direction Is Missing on iPhone: How to Narrow It Down
A missing bucket on iPhone can come from several places, and the test tool itself can only tell you which direction failed to reach the page. Use the list below to walk back through the most common causes in the order they are easiest to check on the device itself.
- Device capability. A traditional vertical wheel will not produce horizontal events regardless of the test. A Magic Mouse or a trackpad usually will, but iOS may not surface the horizontal axis on every model or firmware version.
- Browser interception. Safari can swallow wheel events for its own gestures before the page sees them. Try the test with the page in a stable viewport, no zoom, and a quiet gesture setup so the browser has less reason to keep the event.
- Accessibility and pointer control settings. The iOS settings that govern external pointing devices both influence how scroll is reported. A setting that remaps scroll to a different action will change what reaches the test.
- Remote desktop software. If the iPhone is acting as a remote client, the wheel event may be generated by the host rather than the iPhone, and the host browser decides the magnitude, the direction, and whether the event is delivered at all.
- Test method. The pointer has to be inside the dashed zone when the wheel moves. Events that arrive before the pointer enters the zone, or after it leaves, are not counted and that can look like a missing direction even when the input device is working.
If a hardware decision depends on the result, the page itself cannot answer it. The tool is not a mouse polling-rate checker, input-latency test, hardware diagnostic, repair guide, or accessibility assessment. Manufacturer diagnostics and qualified support are the right next step when a device has to be serviced, replaced, or returned, because browser wheel events cannot reveal a USB polling frequency, encoder bounce, radio quality, or driver health.
Finally, remember the session boundary. All counts, deltas, and cumulative sums live in the current tab. Refreshing the page, closing the tab, or tapping Reset test clears the session and returns every counter to zero. Nothing is uploaded, nothing is saved across sessions, and the widget does not request hardware permissions or listen outside its test area, which is why it is safe to run the test repeatedly while you compare devices, browsers, and gesture settings on the same iPhone.
If you're weighing options, How to Test a Mouse Scroll Wheel in Your Browser covers this in detail.