Convert menus to use OverlayPortal

[gspencergoog]

Description

This converts the MenuAnchor class to use OverlayPortal instead of directly using the overlay.

Related Issues

• Fixes MenuAnchor menus should use OverlayPortal #124830

Tests

• No tests yet (hence it is a draft)

[gspencergoog]

@LongCatIsLooong @Piinks

Is ignoring missing RenderAbstractViewports here a bad idea? I needed to make this change because it used to assert when Scrollable.ensureVisible finds a Scrollable in the widget tree, but it doesn't have an associated RenderAbstractViewport in the render tree, because the OverlayPortal is moving (I think?) the render objects into the overlay.

The menu items scroll just fine, so I think it is calling ensureVisible on the Scrollable in the menu (which is in the overlay), but then when it keeps going up the widget tree to make sure that nested scrollables are visible, it finds a Scrollable that isn't an ancestor anymore in the render tree.

[LongCatIsLooong]

Uh if I write position.ensureVisible using a RenderObject that's not even in the subtree, with the new implementation it would fail silently?

My understanding is ensureVisible only adjusts the scroll offets on scrollable containers to make something visible. So using Scrollable.ensureVisbile for revealing a focused widget may not work well in some cases. If a widget creates an Overlay, to make one of its children visible, it can also change the positioning of these children to reveal the child? If the child is behind some other children then no matter how you scroll the scrollable containers it will still be obstructed?

[gspencergoog]

Uh if I write position.ensureVisible using a RenderObject that's not even in the subtree, with the new implementation it would fail silently?

Yes, it would ignore requests to make a render object visible that isn't a child of a viewport.

So using Scrollable.ensureVisible for revealing a focused widget may not work well in some cases.

Yes, you're right that ensureVisible only affects scrollable regions: it doesn't do anything to move things out of the way or otherwise move the widgets around. It would be pretty challenging to get that right, given all the ways that the widgets could be laid out. Scrolling things doesn't work in all cases, but it does in the most common case where you've hit tab while at the end of a list, and you want to scroll the list to show the newly focused thing.

[Piinks]

I think its ok... my first thought was a ScrollPosition should always have a viewport, since it is a subclass of ViewportOffset, and if we have made it here and there is not viewport something may have gone terribly wrong...
But reading through the comments here I think it makes sense in this case when the render objects are in transit to the overlay.

[LongCatIsLooong]

I'm not sure I understand this part. From the code being _isTopLevel means the _MenuAnchorState's parent is the root node. So I'm assuming _isTopLevel == true is unique in every path (from the leaf _MenuAnchorState to the root) . If that's true then handle._parent!._isTopLevel can only be true for one single node in each path, then I think either the while should just be an if, or the condition actually should be negated?

[gspencergoog]

The top level node is the child of the root node that is the ancestor of (or equal to) the handle node. This code walks up the focus path until it finds the _MenuAnchorState ancestor for which _isTopLevel returns true. Yes, only one node in the path will match _isTopLevel == true, but it's more efficient to walk up the path than to check to see if one of the top level nodes has a descendant that is equal to handle.

[LongCatIsLooong]

Shouldn't the condition be handle._parent != null && !handle._parent!._isTopLevel so the while actually loops?

[gspencergoog]

OMG. You're right, it should be negated.

[LongCatIsLooong]

Created #136769.

[LongCatIsLooong]

LGTM

[Hixie]

Per comment in #146764, this may have regressed correctness in DropdownMenus.

[Hixie]

...for which there is a fix in #147057