Open React-Select does not follow "window" scroll

[wwqrd]

Can be seen when editing an EditableList item, such as a prompt.

Could be:

• Intended behaviour
• Issue with our implementation

If issue with our implementation we should update to fix.

[wwqrd]

I did a little bit of investigation with this:

• The anchoring problem disappears if we remove: menuPortalTarget={document.body}, which positions the div relatively.
• When the menu is positioned relatively, we run into zIndex issues - which I wasn't able to resolve.

One further area of investigation might be to piggyback the portal providing class used by modals, this would mean that we could insert the menus relative to the scrolling div.

[jthrilly]

https://codesandbox.io/s/43n7z1v374?from-embed

This shows a potential approach.

[jthrilly]

I am removing this from the beta release for now, as there don't seem to be any easy fixes.

[jthrilly]

Could perhaps use overscroll-behavior: contain?

https://codepen.io/aaroniker/pen/ZEzmzxj

[wwqrd]

React-select already does something similar to overscroll-behavior: contain I think?

Something similar which seems like it would solve the issue would be to use the menuShouldBlockScroll option. This disables scrolling outside the selector whilst it is open. However this feature is currently broken in react-select: JedWatson/react-select#3929 Suggest we wait until it's fixed there and try again.

[wwqrd]

The react select issue has moved to: JedWatson/react-select#4088

[jthrilly]

One additional consideration here is window height. Native select elements are able to overlap window boundaries:

This isn't ever going to be possible with the current approach as far as I can tell, which means we will always have issues where the list is longer than the remaining offset from the bottom of the select element. Perhaps we are making a headache for ourselves?

Two solutions:

• Use a native <select> and abandon the "rich" element of this.
• Design a different interaction for choosing an input control.

My view is we should implement the first one in the short term, to resolve this issue. We can then earnestly think about the second one, and revisit the intention of rich select items for choosing an input component. The original design was some sort of full screen "chooser" with a summary component.

Alternatively, we could go straight to number 2. Happy to hear what others think!