fix: detect autofilled values on focus for controlled inputs

[DukeDeSouth]

Human View

Summary

Fixes #1159 — an 11-year-old bug where browser autofill breaks controlled components.

When browsers autofill form fields (saved passwords, address autocomplete, password managers), they may set the input value without firing input or change events. This causes controlled components to have stale state — the user sees filled data but React state remains empty. On form submission, data is lost.

Root Cause

React's ChangeEventPlugin detects value changes via getTargetInstForInputOrChangeEvent(), which only checks values when input or change DOM events fire. When browsers autofill without events (e.g., Chrome on iOS, some password managers), React never checks and never fires onChange.

Fix

Add value change detection on focusin events for text inputs. The focusin event is already registered as a dependency of onChange but was unused for modern browsers. When a user focuses an autofilled field, React now checks if the DOM value differs from its tracked value (via updateValueIfChanged()) and fires onChange if so.

This is safe because:

• updateValueIfChanged() compares the value tracker with the actual DOM value — if they match, no event fires (zero false positives)
• focusin already bubbles to the root and is captured by React's event delegation
• Browsers expose autofill values after the first user interaction (focus)

Change

1 function modified in ChangeEventPlugin.js (+7 lines):

function getTargetInstForInputOrChangeEvent(domEventName, targetInst) {
  if (domEventName === 'input' || domEventName === 'change') {
    return getInstIfValueChanged(targetInst);
  }
  // NEW: Detect browser autofill on focus
  if (domEventName === 'focusin') {
    return getInstIfValueChanged(targetInst);
  }
}

Coverage

Scenario	Before	After
iOS Chrome autofill (no events)	onChange never fires	onChange fires on focus
Desktop autofill (events suppressed)	onChange may not fire	onChange fires on focus
Password manager fill	Inconsistent	onChange fires on focus
Normal focus (no autofill)	No onChange	No onChange (correct)
Focus after typing	No extra onChange	No extra onChange (correct)

Known Limitations

• If the user never focuses any field and submits directly, autofill values won't be detected (rare edge case)
• Multiple autofilled fields require each to be focused individually
• Pre-hydration autofill needs a separate fix

Test Plan

• 3 new tests added to ReactDOMInput-test.js
• All 127 tests in ReactDOMInput-test pass
• All 3812 tests across 129 react-dom test suites pass (0 regressions)

---

AI View (DCCE Protocol v1.0)

Metadata

• Generator: Claude (Anthropic) via Cursor IDE
• Methodology: AI-assisted development with human oversight and review

AI Contribution Summary

• Root cause analysis through code tracing
• Solution design and implementation
• Test development (3 new test cases)
• Edge case analysis and verification

Verification Steps Performed

1. Reproduced the reported issue
2. Analyzed source code to identify root cause
3. Implemented and tested the fix

Human Review Guidance

• Verify the root cause analysis matches your understanding of the codebase
• Core changes are in: ChangeEventPlugin.js, ReactDOMInput-test.js
• Verify edge case coverage is complete

Made with M7 Cursor

[meta-cla]

Hi @DukeDeSouth!

Thank you for your pull request and welcome to our community.

Action Required

In order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you.

Process

In order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA.

Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with CLA signed. The tagging process may take up to 1 hour after signing. Please give it that time before contacting us about it.

If you have received this in error or have any questions, please contact us at [email protected]. Thanks!

[meta-cla]

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Meta Open Source project. Thanks!

[afurm]

Nice fix — this is one of those “it’s obviously broken in real browsers, but hard to model in events” issues.

Hooking the existing value-tracking check (getInstIfValueChanged / updateValueIfChanged) up to focusin feels like the right level of pragmatic: it reuses the tracker, it’s naturally deduped, and it lines up with when users actually discover autofilled values (first interaction / focus). The added tests cover the important cases: untracked autofill detected on focus, no-op focus doesn’t emit, and no duplicate after a normal input event.

Only thing to call out: for controlled inputs this can now fire onChange on focus if the browser already populated the value. I think that’s the least surprising outcome overall, but might be worth a quick note in release notes if you track behavior changes like that.

LGTM.