[Kgupta62]

What?

Closes #38865

Ignores the drag-to-change-value gesture on touch devices in InputControl, and therefore in NumberControl and UnitControl too.

Why?

The gesture has no cursor affordance on touch, so nothing tells you it exists, and it is easy to trigger by accident: a flick while trying to tap into the field or move the caret changes the value instead. #38865 also notes the gesture doesn't behave well on touch to begin with, since browser scrolling isn't suppressed for it.

How?

InputField's useDrag handler now returns early when the gesture comes from a touch pointer — event.pointerType === 'touch', or a touch* event where PointerEvent isn't used. Mouse and pen dragging are untouched, and no other behaviour of the control changes.

Added a unit test that drives the gesture with touch events and asserts onChange is never called and the value is unchanged. Without the fix the test fails with two onChange calls.

Testing Instructions

1. Open a post and add a Group block, then open Styles → Dimensions so a UnitControl/NumberControl is visible (padding, for example).
2. On a touch device — or in DevTools with device emulation and touch input — press on the number field and drag up or down.
3. The value should stay unchanged, and you should be able to tap into the field normally.
4. On a desktop browser with a mouse, drag up/down over the same field: the value should still change as before.

Unit tests:

npm run test:unit -- packages/components/src/number-control

Testing Instructions for Keyboard

Focus the number field and use ArrowUp/ArrowDown, and Shift+ArrowUp/ArrowDown — stepping is unaffected by this change.

Use of AI Tools

AI tooling (Claude Code) was used while investigating the issue, drafting the change and writing the unit test. I reviewed the result, confirmed the test fails without the fix and passes with it, and take responsibility for the code in this PR.

[github-actions]

Warning: Type of PR label mismatch

To merge this PR, it requires exactly 1 label indicating the type of PR. Other labels are optional and not being checked here.

• Required label: Any label starting with [Type].
• Labels found: .

Read more about Type labels in Gutenberg. Don't worry if you don't have the required permissions to add labels; the PR reviewer should be able to help with the task.

[github-actions]

Warning: Type of PR label mismatch

To merge this PR, it requires exactly 1 label indicating the type of PR. Other labels are optional and not being checked here.

• Required label: Any label starting with [Type].
• Labels found: .

Read more about Type labels in Gutenberg. Don't worry if you don't have the required permissions to add labels; the PR reviewer should be able to help with the task.

[aduth]

There are already two pull requests opened against the original issue #68514 and #68529, and all three of these have different approaches. Would you perhaps want to weigh in on those other pull requests as compared to your own?

[Kgupta62]

@aduth Sure — I went and read both, plus the use-gesture internals, so here's where I landed. Short version: I don't think any of the three is obviously "the" answer, but they fail in different ways.

First a fact that matters for all three. Our useDrag config only passes pointer: { capture: false }, so use-gesture's device resolver picks pointer on any browser with PointerEvents — which is every current mobile browser. So event.pointerType is populated and trustworthy in the handler, and it only falls back to raw touch events on pre-PointerEvent browsers. It also means preventScrollAxis resolves to undefined, so use-gesture never calls preventDefault() on touchmove itself — it relies entirely on CSS touch-action. That last bit is the important one.

#68529 (touch-action: none) — I think this one is inverted. touch-action: none is what you add to make a pointer drag work on touch, not to stop it. use-gesture warns about it in dev in as many words: "The drag target has its touch-action style property set to auto. It is recommended to add touch-action: 'none' so that the drag gesture behaves correctly on touch-enabled devices." And the issue says the same — mirka wrote that the gesture "will not work nicely on touch devices unless we disable browser scrolling with touch-action: none", and then separately concluded she'd rather disable the gesture. Today the browser claims a vertical swipe as a scroll and fires pointercancel, which is exactly why the bug feels like "a flick nudges the value and then the page scrolls". Take the scroll claim away and the drag stops getting cancelled, so accidental changes get easier, not harder.

Separately: the rule lands on the Input styled component in input-control-styles.tsx, which every InputControl renders — SearchControl, the ColorPicker hex field, PaletteEdit's name field, all the spacing/border controls. So on mobile you'd no longer be able to scroll the sidebar if your finger starts on a text field, and pinch-zoom starting on an input would be dead. Much bigger blast radius than the issue asked for.

I could be wrong — the screencast there does look like it stops the drag. But mirka's issue explicitly notes DevTools mobile emulation behaves differently from a real iPhone, so I'd want a real-device re-check before that one is judged either way.

#68514 (isTouchDevice() gating isDragEnabled) — this does work, and it's the cheapest at runtime since the gesture never gets bound at all. Two things bug me. The detection is 'ontouchstart' in window || navigator.maxTouchPoints > 0, which is true on any Windows touchscreen laptop or Surface — those people have a mouse and a visible ns-resize cursor, and the drag would silently stop working for them. use-gesture's own isTouchScreen() uses maxTouchPoints > 1 specifically to dodge that false positive. And 'ontouchstart' in window is true in jsdom, so drag ends up disabled across the whole unit suite; nothing breaks today because there are no drag tests, but it makes writing one awkward. It's also NumberControl-only, while isDragEnabled is public API on InputControl itself.

Mine does the check per gesture rather than per device (pointerType === 'touch', with a touch-event fallback for old browsers), so a touchscreen laptop keeps mouse drag and loses touch drag, and it sits in input-field.tsx so InputControl/NumberControl/UnitControl are covered at once.

Being fair, mine isn't free of problems either. use-gesture still runs the whole gesture pipeline on touch and I throw the result away, which #68514 avoids. And my test is weaker than it looks: jsdom has no PointerEvent, so use-gesture resolves to the touch device there and the test only exercises the touch-event fallback — the pointerType === 'touch' path that actually runs on a real phone isn't covered by it. I'd rather say that than let it look better tested than it is.

One thing none of us handled: pen. pointerType === 'pen' still drags in my version. A stylus has no cursor affordance either, so it's arguably the same bucket as touch — though it's precise enough that keeping it might be right. Worth being a decision rather than an accident.

The use-gesture touch-action warning also keeps firing in dev with my patch since I leave it at auto. A touch-action: pan-y scoped to drag-enabled inputs is probably the tidy long-term answer, and none of the three do that.

So: I'd argue against #68529 as it stands, and I think #68514 needs the detection moved off a global capability sniff — at which point it converges on what I've got. But I don't have a strong claim on this being my patch. #68529 was first and Infinite-Null had the right instinct about what to disable. Happy to fold the useful bits into whichever one a maintainer wants to carry forward, or to close mine if you'd rather one of the originals land with the per-pointer-type check applied.

[ciampo]

Some thoughts:

• #81519 (this PR) has the correct architecture. It checks the actual pointer event in the shared InputField, so it ignores touch, while mouse dragging still works on touchscreen laptops. It also keeps direct InputControl, NumberControl, and UnitControl behavior aligned.
• #68529 should not land. touch-action: none suppresses native scrolling and zooming and can make touch dragging more reliable—the opposite of the goal. It also affects every InputControl. This follows the Pointer Events specification.
• #68514 uses the wrong signal. Device detection disables mouse dragging whenever a device also supports touch. It also places the policy below the public InputControl.isDragEnabled contract.

These changes are also quite difficult to test systematically (at least in the current setup), so they should be ideally tested on a real touchscreen device (value stability, tapping/caret movement, sidebar scrolling, and pinch zoom).

Also, I would not add touch-action: pan-y only to silence the development warning. This PR intentionally does not support touch dragging, and pan-y can restrict native panning or zooming. dragDirection is not always vertical either. Keeping touch-action: auto is safer than changing browser behavior for an unsupported gesture.

Let's also rebase and solve conflicts.

[ciampo]

Let's describe this as a touch input, rather than touch device

Suggested change

	// The drag gesture is not offered on touch devices, where there is
	// no cursor affordance for it, and where it's easy to accidentally
	// change the value when only meaning to tap or move the caret.
	// The drag gesture is not offered for touch input, where there is
	// no cursor affordance for it, and where it's easy to accidentally
	// change the value when only meaning to tap or move the caret.

Let's make similar changes to CHANGELOG and test names

[Kgupta62]

Good point, taking the suggestion and mirroring the wording change across the CHANGELOG and test names too.

[ciampo]

The onChange assertion already catches the regression. The value assertion may not: this is a controlled component with value="5", so React can restore the input to 5 even if the drag incorrectly called onChange.

Could we either remove the value assertion or render StatefulNumberControl so the displayed value changes when onChange fires?

[Kgupta62]

Right, the value assertion doesn't actually isolate anything here since it's a controlled component. I'll drop it and switch to StatefulNumberControl so the DOM value reflects a stray onChange.

[Kgupta62]

@ciampo applied the wording, and mirrored "touch input" in the CHANGELOG and test name. The test now renders a stateful NumberControl so a stray onChange would show up in the DOM value. Also rebased on trunk.

[mirka]

Everything looks good, but we should try moving the drag tests to a browser mode test.

[mirka]

Sounds like this would be better as a vitest browser mode test, since we have that infrastructure now.

[github-actions]

🤖 PR meta 🤖

🎉 Props

Unlinked Accounts

The following contributors have not linked their GitHub and WordPress.org accounts: @capoomalek.

Contributors, please read how to link your accounts to ensure your work is properly credited in WordPress releases.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Unlinked contributors: capoomalek.

Co-authored-by: Kgupta62 <kuber8821@git.wordpress.org>
Co-authored-by: mirka <0mirka00@git.wordpress.org>
Co-authored-by: ciampo <mciampini@git.wordpress.org>
Co-authored-by: aduth <aduth@git.wordpress.org>
Co-authored-by: SohamPatel46 <sohampate1@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

Updated as activity occurs, without notifying anyone named here. Add the props-bot label to refresh.