Skip to content

fix(RAC): move native input inside the combobox div#9554

Merged
snowystinger merged 1 commit intoadobe:mainfrom
lixiaoyan:patch-12
Feb 6, 2026
Merged

fix(RAC): move native input inside the combobox div#9554
snowystinger merged 1 commit intoadobe:mainfrom
lixiaoyan:patch-12

Conversation

@lixiaoyan
Copy link
Contributor

We have some form binding logic that depends on native form elements being inside the ref element. The current implementation of ComboBox breaks this design. This also makes it more difficult to access the native element for certain reasons (unless we add an extra div wrapper outside). I suggest changing the rendering structure of ComboBox to be consistent with Select, rendering the native form element inside the div instead of as a sibling.

Closes

✅ Pull Request Checklist:

  • Included link to corresponding React Spectrum GitHub Issue.
  • Added/updated unit tests and storybook for this change (for new code or code which already has tests).
  • Filled out test instructions.
  • Updated documentation (if it already exists for this component).
  • Looked at the Accessibility Practices for this feature - Aria Practices

📝 Test Instructions:

🧢 Your Project:

We have some form binding logic that depends on native form elements being inside the ref element. The current implementation of ComboBox breaks this design. This also makes it more difficult to access the native element for certain reasons (unless we add an extra div wrapper outside). I suggest changing the rendering structure of ComboBox to be consistent with Select, rendering the native form element inside the div instead of as a sibling.
Copy link
Member

@snowystinger snowystinger left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm mostly fine moving it, it doesn't have the same issue as Select #8419 but I like having everything contained within a single root per component when possible.

It hasn't broken any of our tests.

My only hesitations is if anyone else ran into the same issue you did and worked around it by looking at the sibling. Overall though, I think this make more sense.

Going to run chromatic (VRT) on it.
Passed https://www.chromatic.com/build?appId=5f0dd5ad2b5fc10022a2e320&number=1106

Copy link
Member

@devongovett devongovett left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess if we want to be consistent we should do the same for DatePicker etc.

@snowystinger snowystinger added this pull request to the merge queue Feb 6, 2026
Merged via the queue into adobe:main with commit fb50ecb Feb 6, 2026
30 checks passed
@yihuiliao yihuiliao added the no testing Does not require manual testing during testing session label Feb 9, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

no testing Does not require manual testing during testing session ready for review

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants