Detect Inserter bounds collision by generic Popover component

[aduth]

Closes #1098
Closes #1004

This pull request seeks to resolve an issue where the inserter is clipped by the editor bar when opened on a new post. A Popover component has been extracted from InserterMenu to provide a generic solution to tooltip-like behavior, including boundary collision detection. When the component mounts or its desired position changes, if it exceeds the viewport boundaries, its direction will be flipped.

Implementation notes:

Similar to as observed in #839, it is difficult to know from the context of the Popover component the bounds of the editor canvas. In this implementation I merely check whether it exceeds the bounds of the entire page (top = 0, left = 0). This could benefit from extensibility allowing the editor layout to override the default bounds (again, since the component is generic, we should not bind it to the editor use-case).

Testing instructions:

Verify that there are no regressions in inserter behavior.
Verify that the editor bar inserter continues to open downward.
Verify that in a post with sufficient content, the inserter opens upward.
Verify that if the inserter were to overlap with the editor bar, it opens downward instead.

[mehigh]

@aduth
As I looked into your PR and the comments inside it
"Verify that if the inserter were to overlap with the editor bar, it opens downward instead"
This is something my simpler implementation does not cover right now, as I didn't experience this specific thing myself.

Nonetheless increasing the min-height of the overflow element is needed in your implementation to improve it even further.

[youknowriad]

I think if we store forced positions like this { forceYAxis: 'top', forceXAxis: 'left' } we could simplify the logic here and avoid some loops.

[youknowriad]

I really like this generic component, great improvement. I think we should make the arrow optional and use this component for:

• Block Toolbars
• Dropdown menus (block switcher, post schedule, post visibility...)

Granted this could be done separately.

Some notes:

• Should we recompute if the window is resized?
• Should we recompute if the popover size/position changes?

[aduth]

Nonetheless increasing the min-height of the overflow element is needed in your implementation to improve it even further.

Can you clarify the need here? I did find that originally I'd needed to change an overflow: auto; to overflow: visible; in the layout styling, but that this was no longer necessary when I rebased because the overflow was removed altogether in 7658b48.

[aduth]

• Should we recompute if the window is resized?
• Should we recompute if the popover size/position changes?

Yes to all of the above. It should already recompute if position changes. "Size" is hard to measure; maybe children changes? But those changes are difficult (impossible?) to detect (related).

[aduth]

I think if we store forced positions like this { forceYAxis: 'top', forceXAxis: 'left' } we could simplify the logic here and avoid some loops.

This simplified things a fair bit. Was able to drop both deep equality check and the reduce in 8ac1fd2.

[mehigh]

@aduth you can take a look over what I committed last on #1192 and see whether it comes in handy or not for wrapping up the solution for this.

Thanks!

[youknowriad]

LGTM 👍 It'd be great to have this merged soon, this is an annoying bug :)