[useSelect][useCombobox] Create prototype to have only useDownshift that covers both scenarios.

[raunofreiberg]

• downshift version: 4.0.5
• node version: n/a
• npm (or yarn) version: n/a

What happened:

When it's possible to scroll the document, opening the menu scrolls to the bottom of the page, when using useSelect with a portal.

Reproduction repository:

https://codesandbox.io/s/useselect-usage-0ifnq

[raunofreiberg]

I guess a solution would be to always render the portal, regardless of the isOpen state. Although, is it really necessary to have X amount of portals rendered in the page?

[silviuaavram]

I think it's the fact that when we focus the menu, even though it's visually near the button, it's actually at the end of the page DOM-wise. So focus goes to the end of the page.

This is my initial thought.

[raunofreiberg]

If this is of any help, same example with the usage of Downshift render prop API does not scroll the page, though.

https://codesandbox.io/s/useselect-usage-pxxk4

[silviuaavram]

Yeah, the focus on the list is causing your issue. If you are using Downshift / useCombobox you should get the activeDescendant value from the inputProps and use that on the toggle button, for accessibility.

I will leave this issue open, as I am studying the possibility of having only one hook to cover both select and combobox. I split them due to the focus issue and some other things, but I think that I can keep focus on the toggle button and still be accessible, in both cases. Will follow up with a PR for a unified useDownshift prototype and see how it behaves.

Even though the hooks are used that's fine, I think that switching between them to useDownshift should be without any breaking changes. Maybe some renames in stateChangeTypes and TS typings of course. But other than that I aim to make it as painlessly as possible. We shall see.

[silviuaavram]

Closing in favour of moving forward with separate hooks. As part of #907 the list should not be focused anymore, functionality kept, and this bug should be fixed.

[silviuaavram]

We have experimented with keeping the focus on the button, but that breaks accessibility. If focus stays on the button, when menu is open, screen readers will not enter in Forms Mode. To conclude, the focus will stay on the list for now, as ARIA suggests in their documentation.

That being said, I don't think you need a portal for that list, you can achieve the same result with CSS. Or maybe I am missing something.

[raunofreiberg]

That being said, I don't think you need a portal for that list, you can achieve the same result with CSS. Or maybe I am missing something.

Without portal, parent elements with overflow: hidden would clip the menu, which is why we want to render the menu in a portal.

[silviuaavram]

Closing this as I don't have a solution. Either use portal in scenarios scrolling at focus is not needed or try to fix it from css. Thanks for reporting it and sorry it cannot work in this case :(

[raunofreiberg]

We have experimented with keeping the focus on the button, but that breaks accessibility. If focus stays on the button, when menu is open, screen readers will not enter in Forms Mode. To conclude, the focus will stay on the list for now, as ARIA suggests in their documentation.

I'm just curious - does the render prop API of Downshift not keep the focus on the button then, seeing as it can work with portals without scrolling?

Example: https://codesandbox.io/s/useselect-usage-kkouj?file=/index.js

Thanks!