Inputs within an Accordion region are not clickable

[e-cooper]

🐛 Bug Report

This happens due to the overridden onMouseDown event within useSelectableCollection.

🤔 Expected Behavior

Inputs should be clickable from inside of an Accordion region.

😯 Current Behavior

Not all element types are impacted, but inputs are the primary reason for this ticket.

💁 Possible Solution

Perform a further check in the event to target scrollbars if possible.

🔦 Context

We're trying to do something similar to the WAI-ARIA example for Accordion.

💻 Code Sample

https://codesandbox.io/s/fervent-fast-g36d2?file=/src/AccordionItem.js

I also noticed that upgrading to @react-aria/accordion@3.0.0-alpha.2 breaks this implementation with an unexpected error.

[snowystinger]

Thanks for raising this, it's good to know for when we start working again on accordion. It's not a high priority for us at this moment, but you can follow our priorities here: https://github.com/adobe/react-spectrum/projects/1

In the meantime, if you use our hooks, placing a textfield inside the accordion shouldn't be an issue, see https://codesandbox.io/s/bold-rubin-k3dbj?file=/src/App.js

This is because the textfield will stop the mouse event before it bubbles up to the accordion item. You could mimic the same thing if you aren't using our hooks for the input.

[LFDanLu]

Team is thinking about rewriting the accordion hooks so that they don't use the collection hooks within them, feels a bit overkill.

[jackl-stripe]

We're encountering something similar with useGrid. (I can file a separate issue if that'd be helpful, but it seems like the root cause is useSelectableCollection, as mentioned in the original post.) Certain <input /> types and all <select /> tags can't be interacted with. We could stopPropagation inside our input components, as @snowystinger mentioned, but that feels bad and likely to cause some issues for the consumers of those input components down the line.

e.preventDefault is a blunt instrument. If the goal is to "Prevent focus going to the collection when clicking on the scrollbar," as the comment indicates, I wonder if there's a more targeted way to accomplish that?

[devongovett]

Focusable elements like inputs inside a grid are problematic for a host of reasons, and it requires a bit more nuanced handling. For example, once an input is focused, you can no longer use the arrow keys to move between cells because it moves the cursor instead. Support for an edit mode is planned, but a bit complex. See #2328 for details on the expected pattern. For now, we usually recommend moving inputs to a secondary UI such as a dialog opened from the table row. Otherwise, you'll need to do some handling yourself with things like stopPropagation, but be prepared for it to be super tricky to get right. 😄

[henrilouis]

We're encountering this as well, and it's not that they're not clickable, but the first click on an is prevented, requiring two clicks to focus. Using alpha.27.

[snowystinger]

Could you use #6635 (reply in thread) instead? Accordion is pre-release and low priority for us because it can be implemented with native elements that have benefits such as searchable text.