Is close public? If so then it should be added to the API docs that it can't be called during build.

MenuController.close() redirects to close(), so I'll add documentation to MenuController.close()

Considering this is a breaking change, I'm curious whether you think we should close this PR. While all tests passed, this could lead to annoying bugs for end users.

That said, open() currently throws an error during builds since OverlayController.show() is called. I realize now that I overlooked the SchedulerPhase check in the open() method when copying over from MenuAnchor. Considering OverlayController.show() will throw, checking the SchedulerPhase in open() doesn't appear to have any effect.

If you do think we should close this PR, do you think we should add similar phase checking/post-frame callback logic to the open() method?

All the CI checks are passing so by definition this doesn't seem to be a breaking change?

You're right:

A breaking change is one that breaks the tests in the flutter/tests repo, and those need a migration guide.

I'm misusing the term to mean a change that may reasonably break another developer's code. I believe calling close() during didChangeDependencies should have worked before, but implementing this change would break this behavior.

Hypothetically you can reparent a MenuAnchor from one window to another right? I don't think you'll get notified (or not in the .idle phase) if that happens? Or the menu is not supposed to hide if that happens?

I think this is my bigger concern (even if multi-window isn't fully implemented). Should the menu close if I move the menu anchor from one window to another using a global key?

I was trying to write a test to simulate this behavior, but I couldn't figure out if there was a simple way to do so using standard flutter testing libraries. Let me know if you know of a good example widget I can model my tests off of...

In my opinion, it seems more intuitive to leave the menu open if the window changes. This is based on the fact that the RawMenuAnchor's state lives within RawMenuAnchor (rather than on an external variable or on MenuController). AFAIK, the only reason why RawMenuAnchor closes on scroll and on resize is because the overlay isn't rebuilt when the menu anchor is repositioned, so the menu appears fixed on the screen when its anchor changes position. Assuming reparenting using a GlobalKey would lead to the overlay rebuilding with a new anchor position, I think the overlay should reposition upon entering a new window? I could be completely wrong.

Also, if #168785 is addressed, there would no longer be a need to automatically close the menu, since the menu would be expected to always follow its anchor.

To your point, as far as I know, the only way to observe the current view would be to call View.of(context), which would not be notified in the idle phase. If we did want to close the menu on reparenting, I believe I'd have to introduce a different way of listening to view changes.

So this looks a bit different from the original implementation, now the menu will also dismiss on view inset change, if I recall correctly. Is that intended that things like keyboard popping up also dismisses all menus? What if there's a text field in one of the menu items?

You're right, and this is not the intended behavior. The didChangeMetrics docs made it sound as if didChangeMetrics was analogous to MediaQuery.sizeOf(context), but this is not the case. I'll update this code to diff the logical view size.