[fields] DateField focus updates (from #22285, v9.7.0+) leak outside React's act() when combined with async form validation

[parwestblad]

Steps to reproduce

We were unable to reduce this to a minimal sandbox in isolation (a 2-3 field form without other context does not reproduce it) — it reliably reproduces in a full application form with:

1. A react-hook-form form, mode: 'onChange', resolver from @hookform/resolvers/yup (async, even for a purely synchronous schema — yupResolver always returns a Promise).
2. Several TextField/Select (MUI) fields validated via Controller, filled in first via userEvent.
3. A DatePicker/DateField field filled in afterward via userEvent.click() + userEvent.keyboard() + userEvent.tab() (or .type(), or .paste()).
4. Run under Vitest + jsdom + @testing-library/react.

I'm happy to work with a maintainer to build a precise minimal sandbox if the above isn't enough to reproduce on your end — will follow up if I manage to isolate it further.

Current behavior

When a DatePicker/DateField is used inside a form validated with react-hook-form + an async resolver (e.g. @hookform/resolvers/yup), interacting with the date field via @testing-library/user-event after other fields have already been filled in produces recurring React warnings in @mui/x-date-pickers(-pro) 9.7.0 and later:

An update to ForwardRef(FormControl) inside a test was not wrapped in act(...).
An update to DateField inside a test was not wrapped in act(...).
A component suspended inside an `act` scope, but the `act` call was not awaited.

This does not happen on 9.6.0. I bisected every 9.x release between 9.6.0 and 9.13.0 and confirmed the warnings start appearing exactly at 9.7.0.

Diffing the published 9.6.0 vs 9.7.0 tarballs, the change is in internals/hooks/useField/useFieldRootProps.mjs, introduced by #22285 ("Avoid focusing the field on blank space clicks"). Before that PR, a single synchronous handleClick set focused/section state. After it, the work is split between a new handleMouseDown and a reduced handleClick, and click-driven section selection is deferred via containerClickTimeout.start(0, ...). This PR's own inline comment even calls out test environments:

"This branch only matters for click events that arrive without a preceding mousedown (programmatic element.click(), some assistive-technology activations, synthetic event sequences in tests)."

I could not reduce this to a small, fully isolated sandbox (a bare form with 2-3 fields does not reproduce it), but it reproduces reliably and repeatedly (dozens of times, across ~40 different test files) in our real application's forms, which:

• Use react-hook-form with mode: 'onChange' and an async (yupResolver) validation resolver.
• Have several TextField/Select fields validated before the user reaches a DatePicker field.
• Drive the date field via userEvent.click() + userEvent.keyboard() + userEvent.tab() (also reproduces with userEvent.type() on the field group, and with userEvent.paste() instead of keyboard() — so it is not specific to how the value is typed).

Things I ruled out as the cause (all still reproduce the warning):

• Using a single atomic userEvent.type(group, dateString) call instead of separate click/keyboard/tab calls.
• Using userEvent.paste() instead of userEvent.keyboard().
• Wrapping the interaction in an explicit act(async () => { ... }) — this either doesn't help, or (when a Select was touched shortly before) produces a worse warning: The current testing environment is not configured to support act(...), appearing many times.
• Flushing pending timers with act() before/after the interaction, at every step, and with vi.useFakeTimers() + deterministic timer advancement.
• Wrapping the field in a Dialog (in case FocusTrap timing was involved).

Expected behavior

Interacting with a DateField/DatePicker via @testing-library/user-event, in a form with other already-validated fields, should not produce React act() warnings, matching the behavior on 9.6.0.

Context

Upgrading @mui/x-date-pickers-pro (and the other @mui/x-* packages) from an older pinned set of versions to the latest, and needed to determine why our test suite started emitting act() warnings across ~40 test files after the upgrade.

Your environment

npx @mui/envinfo

System:
OS: macOS
Binaries:
Node: 24.x
npm: 11.x
Browsers:
(jsdom via Vitest, not a real browser)
npmPackages:
@emotion/react: 11.14.0
@emotion/styled: 11.14.1
@mui/material: 9.4.0
@mui/x-date-pickers-pro: 9.7.0 through 9.13.0 (reproduces on all; 9.6.0 is clean)
@hookform/resolvers: 5.7.1
react: 19.2.8
react-dom: 19.2.8
react-hook-form: 7.85.0
yup: 1.7.1
@testing-library/react: 16.3.2
@testing-library/user-event: 14.6.3
vitest: 4.1.11
jsdom: 26.1.0

Search keywords: DateField act warning useFieldRootProps

[michelengelen]

Thanks for the thorough bisection, this is exactly the detail that makes timing bugs like this tractable.

Current source (9.13.0, matching what you tested) backs up your suspicion: useFieldRootProps.ts still has two untracked timers, containerClickTimeout.start(0, ...) in handleClick's "all sections selected" branch, and a bare setTimeout in handleBlur. Both go through @mui/utils' useTimeout, a plain setTimeout wrapper, so a callback resolving after userEvent's per-step act() flush can legitimately warn, especially with extra microtask turns from an async resolver elsewhere in the form.

Source reading can't confirm the exact trigger, and your own minimal-sandbox attempts didn't reproduce it either. If you can share a reproduction, we can pin down the call site and the fix.

[parwestblad]

I managed to isolate a minimal reproduction, and it turns out the root cause is simpler (and different) than I originally suspected — it has nothing to do with react-hook-form/async validation. My apologies for the red herring in the original report.

By patching console.error temporarily to capture the actual stack at the point each warning fires, the real call sites are not the two useTimeout-based timers (containerClickTimeout / handleBlur's setTimeout) — those do exist and do fire, but only later, correlated with tab()-driven blurs, and don't independently produce a warning in this scenario. The warnings I originally reported instead trace to synchronous onFocus/onBlur/onEmpty updates fired from native focus/blur transitions:

at Object.onBlur (@mui/material/FormControl/FormControl.mjs:201:9)
at handleBlur (@mui/material/InputBase/InputBase.mjs:396:22)

at Object.onFocus (@mui/material/FormControl/FormControl.mjs:204:9)
at handleInputFocus (@mui/x-date-pickers/PickersTextField/PickersInputBase/PickersInputBase.mjs:301:29)

at Object.onEmpty (@mui/material/FormControl/FormControl.mjs:186:5)
at @mui/x-date-pickers/PickersTextField/PickersInputBase/PickersInputBase.mjs:339:22

Live, runnable reproduction: https://stackblitz.com/edit/vitejs-vite-ts2jeept?file=package.json,vite.config.ts,setupTests.ts,src%2FMinimalRepro.tsx,src%2FMinimalRepro.test.tsx&terminal=dev (run npx vitest run in the terminal — the free @mui/x-date-pickers package is used, no license required)

// MinimalRepro.tsx
import TextField from '@mui/material/TextField'
import { DatePicker, LocalizationProvider } from '@mui/x-date-pickers'
import { AdapterLuxon } from '@mui/x-date-pickers/AdapterLuxon'

export const MinimalRepro = () => (
  <LocalizationProvider dateAdapter={AdapterLuxon}>
    <TextField label="Amount" />
    <DatePicker label="Start Date" />
  </LocalizationProvider>
)

// MinimalRepro.test.tsx
import { render, screen, within } from '@testing-library/react'
import userEvent from '@testing-library/user-event'
import { MinimalRepro } from './MinimalRepro'
import { test } from 'vitest'

test('TextField -> DatePicker focus transition', async () => {
  render(<MinimalRepro />)
  const user = userEvent.setup()

  await user.type(screen.getByRole('textbox', { name: 'Amount' }), '123.45')

  const group = screen.getByRole('group', { name: /start date/i })
  const month = within(group).getByRole('spinbutton', { name: /month/i })
  await user.click(month) // <-- warnings fire here, synchronously, no timers involved
})

Findings from bisecting the repro itself:

• A bare DatePicker alone (no preceding field, single click, nothing else on the page) — no warnings.
• react-number-format is not required — a plain @mui/material/TextField reproduces it identically.
• It requires exactly: a focused field losing focus to a DatePicker gaining focus, in the same render tree.
• Confirmed clean on 9.6.0 and broken on 9.7.0+ with this exact repro (re-verified just now).

Given the stacks point at PickersTextField/PickersInputBase.mjs and plain @mui/material/FormControl, this looks like it might be about how the native focus/blur events are dispatched/batched when focus moves between two different field implementations, rather than the deferred timers — happy to keep digging if useful, but wanted to get this corrected reproduction to you as soon as I had it.

[Anexus5919]

I reproduced this locally and traced it to the exact line. @parwestblad's corrected diagnosis is right that the timers are not involved, and the trigger does come from #22285, but the mechanism is one step further along than the stacks alone show.

Root cause

#22285 changed when DOM focus moves, not just which element gets it.

Before 9.7.0, mousedown was not default-prevented, so the browser (and user-event, which emulates the default action) moved focus during the pointer event, outside any React render.

Since 9.7.0, handleMouseDown in useFieldRootProps.ts calls event.preventDefault() and only sets React state. The actual .focus() now happens from this layout effect in useField.ts:

useEnhancedEffect(() => {
  if (!focused || !sectionListRef.current) {
    return;
  }
  if (parsedSelectedSections === 'all') {
    sectionListRef.current.getRoot().focus();
  } else if (typeof parsedSelectedSections === 'number') {
    const domElement = sectionListRef.current.getSectionContent(parsedSelectedSections);
    if (domElement) {
      domElement.focus();
    }
  }
}, [parsedSelectedSections, focused]);

so focus now moves during React's commit phase. Captured stack for the first warning:

Object.onBlur (@mui/material/FormControl/FormControl.mjs:201:9)
handleBlur (@mui/material/InputBase/InputBase.mjs:396:22)
...
dispatchDiscreteEvent
fireFocusEventWithTargetAdjustment          <- jsdom
HTMLSpanElement.patchedFocus [as focus]     <- user-event patchFocus
@mui/x-date-pickers/internals/hooks/useField/useField.mjs:236:20
commitHookEffectListMount
commitHookLayoutEffects
flushLayoutEffects
commitRoot
performSyncWorkOnRoot
flushActQueue                               <- still inside act
exports.act
@testing-library/react/dist/act-compat.js:46:25
Object.eventWrapper
wrapEvent
Mouse.down

useField.mjs:236 is the domElement.focus() line above.

What actually produces the warning is a nested act():

1. user-event dispatches mousedown inside RTL's eventWrapper, which opens act().
2. React's act runs popActScope() (resetting actScopeDepth to 0) before calling flushActQueue().
3. During that flush, the layout effect calls span.focus(), which blurs the previously focused <input>.
4. user-event's document-level capture blur listener, installed by prepareDocument, sees el.value !== initialValue and calls dispatchDOMEvent(el, 'change'), which goes through wrapEvent and opens a second act().
5. That nested act() sees prevActScopeDepth === 0, treats itself as the outermost scope, and on exit sets ReactSharedInternals.actQueue = null while the outer flush is still running. Its own flushActQueue is a no-op because isFlushing is true, which also leaves the queue non-empty and produces the A component suspended inside an act scope message.
6. Every remaining update in that commit (FormControl onBlur / onFocus / onEmpty, MUI X setSelectedSections, the InputBase effect) now sees actQueue === null and warns.

I confirmed step 5 directly by installing a setter on ReactSharedInternals.actQueue and logging every mutation during the click. The nested act() enters and nulls the queue mid-flush, immediately before the eight warnings.

Step 4's value gate is also measurable, and it explains why a bare DatePicker never reproduces:

interaction with the TextField before clicking the date field	warnings
typed 123.45	9
clicked only, no typing	0
typed x then Backspace, restoring the original value	0
no interaction at all	0

Row 3 has a focus transition identical to row 1. Only the input's value differs, which is exactly the condition guarding the change re-dispatch.

The version that matters is not only the picker version

The reporter pins @testing-library/react@16.3.2. 16.3.3 already makes the symptom disappear with no MUI X change. Diffing the two tarballs, the only functional change in dist/pure.js is a re-entrancy guard added to eventWrapper:

+let inEventWrapper = false;
 (0, _dom.configure)({
   ...
   eventWrapper: cb => {
-    let result;
-    (0, _actCompat.default)(() => { result = cb(); });
-    return result;
+    if (inEventWrapper) {
+      return cb();
+    }
+    inEventWrapper = true;
+    try {
+      let result;
+      (0, _actCompat.default)(() => { result = cb(); });
+      return result;
+    } finally {
+      inEventWrapper = false;
+    }
   }
 });

That guard is exactly what suppresses the nested act() in step 4.

This is also why the mui-x suite never caught it: this repo is on 16.3.3. My first attempt to reproduce inside the repo, using createPickerRenderer and the same gesture, passed with zero console.error calls.

Matrix

All rows measured with the reporter's minimal repro (TextField typed into, then user.click() on the Month section), jsdom, user-event@14.6.3, vitest@4.0.5:

@mui/x-date-pickers	@testing-library/react	warnings
9.6.0	16.3.2	0
9.7.0	16.3.2	9
9.13.0	16.3.2	9
9.14.0	16.3.2	9
9.14.0	16.3.3	0
9.14.0 + candidate fix below	16.3.2	0

React 19.2.0 vs 19.3.0 makes no difference. jsdom 26.1.0 vs 30.0.1 makes no difference.

Immediate workaround

@parwestblad, upgrading @testing-library/react to >= 16.3.3 should clear the warnings coming from this path, with no other change. Worth trying before any picker change lands.

Question for maintainers

Do you want a source-side fix as well, given the RTL fix already exists?

My argument for yes is that this is not purely a test artifact. #22285 moved the field's DOM focus for a pointer click from the pointer event's default action into a React commit. That is observable outside tests: focus lands one render later than native, so anything keyed off blur of the previously focused element (validation, a change dispatch, a document.activeElement read in a userland onMouseDown) now runs during a React commit rather than during the pointer event. Moving focus from a layout effect is also what made the field vulnerable to this interaction in the first place.

The minimal change would be in handleMouseDown: after setFocused(true) and setSelectedSections(parsedIndex), focus the resolved section synchronously, restoring the pre-9.7.0 timing. The existing layout effect then becomes a no-op, since focusing an already-focused element fires no events, so nothing else needs to change. The target resolution would reuse the rule syncSelectionToDOM already applies (section.type === 'empty' goes to the container, otherwise the content span), ideally extracted so the two cannot drift.

I prototyped exactly that against the 9.14.0 build and ran six scenarios: click Month, click Year, click blank space, click then type a full date, click one section then another, click then Tab away. All six produced 0 warnings on RTL 16.3.2, and the resulting selection index and field text were identical to unpatched 9.14.0 in every case.

Two things I have not verified and would need to before opening a PR:

1. Whether an explicit .focus() at mousedown time still works in Chromium while the WebkitUserModify: read-only gate from [fields] Avoid focusing the field on blank space clicks #22285 is active. The field root does not match :focus-within yet at that point, but the CSS condition is identical for the current layout-effect call, so it should hold. Needs the browser and Playwright e2e suites to confirm.
2. Whether any of the existing selection.DateField.test.tsx mousedown cases shift. They assert selection rather than focus, so I do not expect movement, but the full x-date-pickers* run is required.

Happy to open the PR if you want it. If you would rather treat this as fixed upstream in RTL and close, that is a reasonable call too, and the matrix above should be enough for anyone who hits it on an older RTL.

[michelengelen]

Nice work tracking this all the way down — the act() internals here are genuinely gnarly, and the matrix at the end settles the "is this us or RTL" question cleanly.

I checked your read against the current source and it holds up: handleMouseDown in useFieldRootProps.ts calls preventDefault() and only updates React state; the actual .focus() call happens later, in the layout effect in useField.ts. That's a real one-render-later shift from the pre-#22285 behavior, not just a test artifact.

I prototyped the fix you described — focusing the resolved section synchronously inside handleMouseDown (both the blank-space and normal-click branches), leaving the layout effect as a no-op fallback:

     if (isBlankSpaceClick) {
       event.preventDefault();
       if (!focused) {
         setFocused(true);
         setSelectedSections(sectionOrder.startIndex);
+        domGetters.getSectionContent(sectionOrder.startIndex).focus();
       }
       return;
     }
     ...
     setSelectedSections(parsedIndex);
+    domGetters.getSectionContent(parsedIndex).focus();
   });

Full x-date-pickers unit suite (121 files) passes unchanged with this in place, and tsc/eslint are clean. That covers the final-state assertions (selection, section index, callback counts) but not the exact act() interleaving your repro depends on — jsdom + fireEvent already flushes the layout effect inside the same act() call, so it can't distinguish "focused in the handler" from "focused in the effect" the way real userEvent + an older RTL can. So this is confidence that nothing else broke, not a reproduction of the original warning.

On your open question #1: the existing comment in useFieldRootProps.ts next to handleMouseDown ("syncSelectionToDOM ... works even with the user-modify rule active") already answers it — an explicit .focus() bypassing the WebkitUserModify: read-only gate is exactly what the current layout-effect path relies on. Moving that same call earlier in the same synchronous stack shouldn't change whether it works, since nothing changes the container's :focus-within state in between. Still worth confirming with the browser suite before merging, per your open question #2.