Add ignoreVirtual option for useFocusVisibleListener?

[jonaskris]

I think useFocusVisibleListener should have an option to ignore virtual modality, and when virtual modality is encountered, it should instead act as if the last non-virtual modality is active.

The reason why im requesting this, is because i have a search component with a dropdown list to choose an option. Normally, it is rendered like usual in the dom (not open).
When the user opens the search component, it enters fullscreen by rendering it in a react portal on the document body.

The search component being unmounted in one location, and mounted in another, causes it to blur and then focus, which changes modality to virtual. And the focus ring behaviour breaks.

Essentially, any component that should render in another place in the dom when it gains focus, breaks useFocusVisibleListener.

My suggestion is to keep track of the last modality which is not "virtual" (will always be either "pointer" or "keyboard"). Lets call this variable "lastNonVirtualModality".
I would then like useFocusVisibleListener to take a parameter "ignoreVirtual". If ignoreVirtual is true, return the "lastNonVirtualModality" variable, instead of "currentModality".

I can create a pull request for this, but looking for some feedback before i implement it, so i dont waste time implementing something that wont be accepted.

[snowystinger]

Thanks for the discussion.

I don't think we want to do this as focus is being moved to a new place and because that new place is in a completely different (full screen takeover) UI, it's best to inform users where their focus is regardless of input modality. It's auto focus in a dialog.

I don't think you're doing this, but it's worth pointing out that a textfield cannot be a dialog trigger. Instead, for accessibility, the "normal" dom version should be a button (though it may visually look like a textfield). This button then opens a full screen dialog and auto focuses the textfield in there, which is serving as your search.

[jonaskris]

We do use the textfield as a dialog trigger, and any interaction other than tab (when the searchfield is focused) will rerender the search field along with its dropdown in a fullscreen modal.
I've searched for anything regarding what is a valid dialog trigger, but cant find any information excluding text fields as a valid trigger, or any mention of what is a valid trigger. If you have any source for this at the top of your head i would appreciate if you can share it.

Im not entirely sure why, but i tried using useFocusRing before i made this discussion, and other hooks that react-aria exposes, but none of them worked at the time for different reasons.

Probably i dident use the correct react-aria hooks for the job because they overwrote downshift's own "onFocus" and "onBlur" handlers. I learned that downshift supports adding handlers on top of its internal handlers using this pattern {...getInputProps({ ref: inputFieldRef, onFocus, onBlur })}. Now that i know this, i found i can use useFocusRing's returned handlers in addition to downshift's handlers, and everything seems to work as intended.

Seems like it was a mistake to use useFocusVisibleListener instead of the useFocusRing which better fits this useCase.

[snowystinger]

I left off some nuance, textfields can be triggers, but the only examples I know of are things like combobox where focus stays in the original input and focus inside the popover is controlled virtually.

https://w3c.github.io/aria/#listbox

aria-haspopup (deprecated on this role in ARIA 1.2)

Incidentally, we do my recommendation for combobox on mobile in our React Spectrum component.

useFocusVisibleListener is not really public API, that's why it doesn't have a docs page.

[jonaskris]

Alright, thank you for the response and help.

The searchfield im using is indeed a combobox, where at least the dropdown list selection is virtual. But yeah, i do in fact unmount my textfield from its usual place in the dom, and remount it on document body where it gains a new focus event, which might not be optimal, but im afraid i cant spend more time on this feature to improve on that.

Again, thank you for your help :)