`SelectPanel` not scrolling with anchoring element

[reneexeener]

Describe the bug
SelectPanel not scrolling with anchoring element when parent containers have different overflow properties. This also happens with ActionMenu.

To Reproduce
In memex list view:

1. Go to an existing memex project (list view)
2. Click on any downward carets to open the SelectPanel
3. Start scrolling the table
4. SelectPanel does not scroll with the anchoring element that is the table cell

In bulk add side panel:

1. Go to an existing memex project and click on the + icon in the omnibar at the bottom of the page
2. Click on the repository selector to open the SelectPanel
3. Start scrolling the table
4. SelectPanel does not scroll with the repository selector button

In Project settings (implements ActionMenu):

1. Make sure you have admin permissions and go to an existing project
2. Click on the three dots on the top right corner -> Settings -> go to bottom of the page
3. Click on the button next to 'Visibility'
4. Start scrolling the page
5. ActionMenu does not scroll with the button

Expected behavior
SelectPanel and ActionMenu should scroll correctly with their anchoring elements.

Screenshots

Desktop (please complete the following information):

• OS: macOS Montery 12.4
• Browser: Chrome
• Version 103.0.5060.114

Additional context
After doing some deductions with @siddharthkp, we suspect that the scrolling problem is caused by wrapping SelectPanel or ActionMenu in nested containers with different overflow properties, which causes the getClippingRect function to find the wrong parent node (code).

[iansan5653]

I've looked into this a bit before because we see the same thing with InlineAutocomplete suggestions when you scroll the Markdown editor textarea in the side panel:

Screen.Recording.2022-07-25.at.12.35.37.PM.mov

The cause is that all of our overlays render into a Portal at the document root, so the portals all are be positioned relative to the document root. In this case, the table grid is scrolling but the document is not. The only way to fix this without changing Primer is to put a portal inside the grid and render all in-grid overlays into that portal. That would be a nightmare to maintain and we'd have to do it for every single scrollable container in the app. It's actually impossible for the Markdown editor since you can't put a portal inside of a textarea element.

Here's an example:

On the docs page, the panels do scroll with the page because the entire document scrolling:

Screen.Recording.2022-07-25.at.12.17.39.PM.mov

If we put the anchor inside a scrolling container though, the menu does not scroll with its container, though it will still scroll with the document:

Screen.Recording.2022-07-25.at.12.19.09.PM.mov

---

I think the only way to fix this would be to attach a scroll event listener to every ancestor of the anchor element and then recalculate the overlay position when any of those events fire. This seems expensive but maybe we could optimize it by bypassing React to avoid renders (ie, directly set the overlay element's style.top/style.left attributes).

[github-actions]

Hi! This issue has been marked as stale because it has been open with no activity for 180 days. You can comment on the issue or remove the stale label to keep it open. If you do nothing, this issue will be closed in 7 days.

[siddharthkp]

Adding it back to Unprioritized backlog