fix(DateInput): clearing on touch no longer jumps the page to the top - #5350
Open
imdreamrunner wants to merge 1 commit into
Open
fix(DateInput): clearing on touch no longer jumps the page to the top#5350imdreamrunner wants to merge 1 commit into
imdreamrunner wants to merge 1 commit into
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
meta-cla
Bot
added
the
CLA Signed
Contributor
PR Analysis Report📚 Storybook PreviewView Storybook for this PR 🧪 Sandbox PreviewView Sandbox for this PR Modified ComponentsDateInput (@astryxdesign/core) · View in Storybook
Bundle Size Summary
Accessibility AuditStatus: No accessibility violations detected. Generated by PR Enrichment workflow | Storybook | Sandbox | View full report |
imdreamrunner
changed the title
imdreamrunner
force-pushed
the
fix/date-input-clear-scroll-jump
branch
from
August 23, 2026 06:26
41d6cb4 to
102fee1
Compare
On the touch surface, tapping the clear (X) threw the user to the top of the
page. Clearing unmounts the clear button, and handleClear focused the field in
that same task; on iOS Safari, focusing an element as the focused button is
removed scrolls the whole document to 0.
The focus handoff is deferred past the unmount. The page stays put and focus
still lands on the field, so it is not lost to <body>.
Measured on the iOS 26 simulator driving real taps against the live docsite
(DateInput - Clearable, page at scrollY 2055), with every scroll API and the
scroll lock instrumented:
synchronous focus() -> 2055 -> 0
synchronous focus({preventScroll}) -> 2055 -> 0
focus suppressed entirely -> 2055 (no move, focus lost)
deferred focus({preventScroll}) -> 2055 (no move, focus kept)
No script scrolls the page: no scrollTo/scroll/scrollBy/scrollIntoView, no
scrollTop write, no history navigation, no scroll-lock body pinning, and the
document height never changes. preventScroll is kept because the ordinary
scroll-into-view nudge is real too (+12px on a plain page) and unwanted for the
same reason.
imdreamrunner
changed the title
imdreamrunner
force-pushed
the
fix/date-input-clear-scroll-jump
branch
from
August 23, 2026 07:10
102fee1 to
12617af
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The bug
On touch, tapping DateInput's clear (✕) throws the user to the top of the page.
Repro (real, on the live docsite): open
https://astryx.atmeta.com/components/DateInput on a phone, scroll to the second
date input — the DateInput — Clearable example, "Event date / April 6,
2026" — and tap its ✕. The page jumps to the top. React state survives, so it
is an in-page scroll jump, not a reload.
Cause
TouchDateField.handleClearclears the value and focuses the field in the sametask. Clearing unmounts the clear button — it only renders while there is a
value — and on iOS Safari, focusing an element in the same task as the focused
button's removal scrolls the whole document to 0.
Measured on the iOS 26 simulator driving real taps against the live docsite,
field at
scrollY 2055, with every scroll API instrumented:focus()(today)focus({preventScroll: true})<body>)focus({preventScroll: true})What is not happening, all instrumented and silent through the jump: no
scrollTo/scroll/scrollBy/scrollIntoView, noscrollTopwrite, nohistory.pushState/replaceState/hashchange, no scroll-lockbodypinning,and
document.scrollHeightnever changes (5156 throughout, so it is not aheight collapse clamping the scroll). Focus on the same field while the page is
quiet does not move it either — the unmount is required.
The fix
Defer the focus handoff past the unmount. The page stays put and focus still
returns to the field, so it is not lost to
<body>.preventScrollis kept: the ordinary scroll-into-view nudge is real too (+12pxon a plain page) and unwanted for the same reason — the field the user just
tapped is already on screen. It is not sufficient on its own, per the table.
Only the touch surface is affected; the pointer surface is a different
component and does not do this.
Test plan
DateInputTouch.test.tsx: focus is not called synchronously,and after timers run it is called with
{preventScroll: true}. Negativecontrol: restoring the synchronous call fails it.
packages/core/src/DateInput— 229 tests pass.pnpm lint:strict— 0 errors (55 pre-existing warnings).pnpm test— 11376 pass; the 11 failures are allpackages/cli, the knowndevvm full-run load flake, green under
vitest run --project node packages/cli(200 files / 2780 tests).pnpm buildplus thebuild-storybooktypechecks(
core|lab|charts typecheck:docs,cli typecheck:{strict,template-docs},storybook typecheck,core typecheck,lab:readiness:check,storybook build) — all exit 0.Note on earlier revisions of this PR
The first version of this PR changed
DateRangeInput,SelectorandMultiSelector— none of which are DateInput and none of which are the touchsurface. That was wrong and has been dropped. Those three do have a separate,
real defect (their clear leaves focus on
<body>); worth its own PR, not thisone.