[EuiPopover] Expose `repositionOnScroll` in `componentDefaults`

[Dosant]

Part of #8820

While checking some functional test failures in Kibana with the new grid layout, I noticed that the popover position is incorrect in some cases.

In this case, we have a popover that doesn't have repositionOnScroll. It used to scroll correctly, but with the new layout, it doesn't anymore.

The reason for this is that the main application scroll has moved from the document to the inner grid cell.

It is hard to estimate how widespread this issue is, but I'd like to avoid adding repositionOnScroll to each popover manually. Moreover, this seems to be an issue not only specific to the grid layout but also to any popover that we position inside a nested scroll (e.g., flyout or modal).

• Popover inside window - https://codesandbox.io/p/sandbox/popover-scroll-window-gkdg2q
• Popover inside nested scroll - https://codesandbox.io/p/sandbox/popover-scroll-container-wtcl65

Proposals:

• I wonder if we should make repositionOnScroll the default?
• Or at least allow make it configurable as default via default props?
  - Is this option a significant performance overhead?
• any other options or considerations?

[Dosant]

Should also double-check the tooltips.

[Dosant]

I guess another option could be to move the popover element from the document to the actual scrolling container.
I see there is a prop on a popover that might work:

	    /**
	     * Passed directly to EuiPortal for DOM positioning. Both properties are
	     * required if prop is specified
	     */
	    insert?: {
	        sibling: HTMLElement;
	        position: 'before' | 'after';
	    };

[weronikaolejniczak]

@Dosant yet another option that doesn't require updating all popovers now is removing the portalling altogether. @tkajtoch raised this idea during our weekly yesterday. He might have some more thoughts to share here.

We could consider insert or repositionOnScroll as a fallback if we cannot make a change on EUI level.

FYI still didn't get to debugging this issue

[weronikaolejniczak]

Moved back to "Accepted". It's not related to the side nav. It doesn't affect the side nav release because it renders within the current layout.

This will block the release of the new grid layout.

Anybody on the team can take it once capacity allows.

cc @Dosant @elastic/eui-team

[JasonStoltz]

Aiming to tackle this in 2 weeks, pending OK from anton and Petr. Clint is asking.

[weronikaolejniczak]

@JasonStoltz @clintandrewhall @Dosant We had a short conversation about this with Anton and we think that the componentDefaults is the first nice step.

What repositionOnScroll does is it fixes EuiPopover / EuiToolTip positioning on anchors that are position: fixed. That is not always the behavior that we want. It adds listeners and recalculates the position so it isn't without a cost either.

That being said, we have a logic in the tooltip that makes only one be displayed at a time. And usually, popovers do not display at once (or display briefly at once).

The short-term proposal would be:

1. Switch the repositionOnScroll to true by default.
2. Build the @elastic/eui locally.
3. Test within Kibana to see if there is a significant performance overhead or behavior issues (intuition tells me - there won't be).
4. Add EuiPopover and EuiToolTip repositionOnScroll to componentDefaults.
5. Release and update in Kibana.
6. Using EuiProvider, pass the feature flag to repositionOnScroll in componentDefaults. This way, we will have enough time to test the result while not causing potential regression to existing functionality.

Estimation: up to 2 days

Because repositionOnScroll affects the component behavior I would not do it globally within EUI. That being said, through componentDefaults that we hook up to the feature flag for the new grid layout, that might be good!

The long-term proposal would be:

1. Redoing our overlays to not be portaled.
2. Provide better composition (likely, not wrapping the triggers).

cc @elastic/eui-team

[JasonStoltz]

@weronikaolejniczak Sounds like a solid plan to me -- using globalDefaults let's us minimize the impact and verifying in Kibana early de-risks the change.

I assigned this to you and noting that the tentative plan is for you to pick this up after your current work ~beginning of October.

Here are some notes from the Triage Session:

Urgency
This is needed for a Kibana initiatve the Shared UX team is working on. The initiative is targeted for 9.3, but this is a challenge for them currently, so prioritizing soon would be helpful>

Approach
The team discussed whether or not to change the default. The risks being impact to existing usage and potential performance problems. (Weronika outlined an approach above addresses these concerns)

Timing
Weronika has the most context around this and would be best positioned to handle it. She's busy until after her current project completes, so the plan is to work on this when that project completes, in ~2-3 weeks.