What is the purpose of this?

It's Overlay.of but uses an InheirtedWidget (Overlay.of uses context.findAncestorStateOfType<OverlayState>() because we didn't have a declarative API that requires the consumer widget to be notified when the overlay changes).

Also the widget that provides OverlayInfo lives under an OverlayEntry so it knows which OverlayEntry it is from. We can add more (private) information to OverlayInfo when needed.

Is there a reason why OverlayPortal can't do that itself? I'd expect OverlayInfo.of(context) to use the OverlayPortal's Element as context

Not always I think? There're cases you want to put the child on a different Overlay (that's why Overlay.of takes a bool rootOverlay = false I guess. Unfortunately it will be a bit expensive for OverlayInfo.of to get the root overlay and updates its dependents when it changes)

Most of the time it should I think
I'd at least ewpect this parameter to be optional

To be clear, I don't disagree with the value of this parameter.
My only argument is about making it optional and default to obtaining the closest Overlay.

There are definitely use-cases for this parameter. But I don't see value in having to pass OverlayInfo.of(contewt)

To me, that's as if Text's style was required and expected users to do Text('...', style: DefaultTextStyle.of(context))

If we use null for default then unfortunately it can have 2 meanings: either the API user wants to use the default, or we failed to get the OverlayInfo from the given BuildContext the user specified at runtime. You can probably workaround this by creating some const value to represent the default (the closest OverlayInfo), but I think it's better to keep the API simple and stupid in this case.

I wouldn't expect OverlayInfo.of to return null if there's no overlay anyway. I'd expect an exception
So this wouldn't have 2 meanings

Yeah usually we have 2 versions for this kind of things, maybeOf and of. I'll rename Overlay.of to Overlay.maybeOf to follow the naming convention.

But I'm a bit hesitant to only expose the version that throws, especially since this is a query API. It will be a bit awkward for people to do something that could otherwise be really simple to achieve: OverlayInfo.maybeOf(outerContext) ?? Overlay.maybeOf(innerContext).

By popular demand I'll rename the current default constructor and introduce a new default constructor that doesn't take an OverlayInfo?.

Will "mouse" region behave well for mobile phones? If not, maybe we can improve this example since flutter targets on mobiles as well?

This is an interactive example in the documentation and will be shown in a browser so I think in most cases developers will have a mouse connected while checking out the example.

But yeah you're right I'll change it to a button so it's more accessible.

Well I am a bit confused. If assert(false), how can the lines after it be executed? (the result = false etc). Especially considering all these are wrapped in assert((){ }) such that the whole block will only exist in debug build.

I'll change that to throw a FlutterError then.

👀 are these temporary code

@Hixie currently we allow a node to mark itself dirty if there's no ancestors of it calling performLayout. I thought that could cause clean nodes to be re-dirtied? Changing it to setting result to false here doesn't seem to break any tests so I wonder why that was allowed? Is that for global key reparenting between LayoutBuilders?

I do not recall, but yeah, looking at global key reparenting and layout builders (and maybe both together) is definitely where I would start when trying to understand this. cc @goderbauer might have a better idea, he's more familiar with this code these days.

Not always I think? There're cases you want to put the child on a different Overlay (that's why Overlay.of takes a bool rootOverlay = false I guess. Unfortunately it will be a bit expensive for OverlayInfo.of to get the root overlay and updates its dependents when it changes)

This is an interactive example in the documentation and will be shown in a browser so I think in most cases developers will have a mouse connected while checking out the example.

But yeah you're right I'll change it to a button so it's more accessible.

I'll change that to throw a FlutterError then.

moving changes to object.dart into its own PR would be good, given the sensitivity of such changes (e.g. you probably want to try to get low-level changes like this rolled into google3 before doing anything that relies on them)

Given there are so few, do you think it makes sense to credit the other contributors as well? I am not sure myself because looking at the implementation, I do realize that it does differ significantly from the code we wrote.

Ah my apologies. Yeah I can pull the list from the bottom of this page: https://pub.dev/packages/flutter_portal. Alternatively there's an AUTHORS file, do you prefer to be added there instead (also @rrousselGit @fzyzcjy).

I do not really have a preference there 👍

this seems like a really inefficient way of implementing:

if (_child != null) visitor(_child);
if (_overlayChild != null) visitor(_overlayChild);

Am I missing something?

Didn't want to create 2 local variables just for promoting them to non-null types I guess.