Is it guaranteed at this point that the render object is already laid out?

I was hoping you would know :) This method is the overlayChildBuilder of an OverlayPortal, and _fieldKey is in the child of the same OverlayPortal.

If the sizing rule (BoxConstraints => Size) is known (in other words the child is sized by the parent) I think you could use a layout builder as the ancestor of the text field to get the size of the text field. Otherwise I think it's a bit trickier.

Done and it seems to work, thanks.

Question: Should I add a flag for this, or even pass the Size to the optionsViewBuilder and make users include the UnconstrainedBox and SizedBox? I figure most users do want this width-matching behavior, which is why I made it mandatory, but it could be a breaking change for some...

I agree that most users will want this width-matching behavior — I think it's the standard expectation which most end users are accustomed to from other GUIs.

A flag would be reasonable, because I do sometimes see UIs where there's a small dropdown field but when you open it the options are much wider, so there'll surely at some point be a Flutter developer who wants that behavior. I think it'd be best for width-matching to be the default, though, because that's the behavior most people will expect. My suggestion would be to go ahead and make it the only behavior, and then adding a flag can be a follow-up if and when people ask for it.

If users had to include the UnconstrainedBox and SizedBox themselves, I think that'd make this only a like 20% solution, because that'd sound complicated and I expect most developers just wouldn't do it. (With enough docs, it could be maybe a 70% solution; even then, I'd expect to continue getting reports of #78746.) It definitely feels to me like the kind of detail I'd expect the autocomplete widget itself to have responsibility for.

Thanks for the analysis, I'm on board with this. I'll leave this as-is but add a TODO with a link to this thread if/when someone starts asking for it.

I'm surprised that no test caught this, but I think this will crash if the autocomplete widget is not in a layout builder. The _fieldBoxConstraints variable won't be assigned until the layout phase.

As a workaround, putting the widget that takes that BoxConstraints in a layout builder will defer the evaluation of the late variable to the layout phase.

Overlay portal always lays out the child branch before the overlayChild branch so I think this should be safe (but I think the trick makes enough assumptions about layout builder's implementation and overlayportal's implementation, to merit throughout comments/testing)

Here's my attempt: 49f98d6. Can you take a look at that and tell me if it's possible to get OverlayPortal to build overlayChildBuilder in the same frame as it builds child? I wasn't able to reproduce it, though I get what you're saying and it is worrying.

Try letting it build a field view that has a Focus(autofocus: true)?

Ah that probably doesn't work since the focus callback won't get called until the next microtask flush. If it's guaranteed that the options view won't show the same frame the field view shows, that should be safe (but _fieldBoxConstraints will still have a one frame delay).

Ok got it, I've removed the LayoutBuilder, the test, and adjusted my comments. I will keep an eye out though in case anyone runs into this.

I think the layout builder is probably still needed. If the text field gets a set of different input constraints, then this variable is going to change, but nothing is telling the menu to resize if it's already open?

Well I guess OverlayPortal needs a new constructor that takes a overlayChildLayoutBuilder which gives you the size of the child before you build the overlay child.

(Because the text field itself may change size, e.g., when there's an animation that resizes it)

Good point, I confirmed that the options weren't rebuilding with the new width when the field constraints changed. Now I've updated it with a ValueNotifier so that they do, but I agree a new constructor on OverlayPortal would be nice. What do you think of my approach, and do you think I should add something similar to OverlayPortal or keep that for a separate PR?

I agree that most users will want this width-matching behavior — I think it's the standard expectation which most end users are accustomed to from other GUIs.

A flag would be reasonable, because I do sometimes see UIs where there's a small dropdown field but when you open it the options are much wider, so there'll surely at some point be a Flutter developer who wants that behavior. I think it'd be best for width-matching to be the default, though, because that's the behavior most people will expect. My suggestion would be to go ahead and make it the only behavior, and then adding a flag can be a follow-up if and when people ask for it.

If users had to include the UnconstrainedBox and SizedBox themselves, I think that'd make this only a like 20% solution, because that'd sound complicated and I expect most developers just wouldn't do it. (With enough docs, it could be maybe a 70% solution; even then, I'd expect to continue getting reports of #78746.) It definitely feels to me like the kind of detail I'd expect the autocomplete widget itself to have responsibility for.

I think the layout builder is probably still needed. If the text field gets a set of different input constraints, then this variable is going to change, but nothing is telling the menu to resize if it's already open?

Well I guess OverlayPortal needs a new constructor that takes a overlayChildLayoutBuilder which gives you the size of the child before you build the overlay child.

Why the UnconstrainedBox? The overlay should be large enough to accommodate the menu I think?

Without that the width of the SizedBox is not respected and the options are always full width. I think being in an Overlay gives it weird constraints.

Maybe use Positioned instead?

That doesn't seem to work because of the CompositedTransformFollower widget. Without that Positioned does work like you said.

Positioned has to be placed as the root of the overlay child. I think the problem is the overlay is giving the overlay child tight constraints.

Ah that worked, thanks.

Actually, with Positioned it was completely unconstrained in both directions, which caused layout errors in the options builder. I changed it to use ConstraintsTransformBox to just loosen the constraints in both directions, what do you think of that?

Talked offline: I should try setting the width at the Positioned widget instead of below in a SizedBox.

Maybe use Positioned instead?

Is this still needed?

No, good catch.

If the input field has textWidthBasis = TextWidthBasis.longestLine (in which case the text field is not going to take the full available width) does this work still?

You're right, and this comment is making me realize that what we're doing here isn't matching the width of the field necessarily, it's just matching the width of the constraints given to the field. Here's a screenshot of your idea where yellow is the Autocomplete and blue is the EditableText:

It doesn't even need to be anything as fancy as TextWidthBasis; if you just hardcode the width of the field to something other than the constraints, then it's the same kind of result:

However, I think that's kind of the best that we can do. If users are sizing their text field in a weird way and they want the options to match that width, they'll need to look up its width using a GlobalKey and a post frame callback. Most people are probably doing that today without this PR.

My best guess is that giving the same constraints as the Autocomplete is probably what most users will want and expect.

If the options view is also in a layout builder I don't think the post-frame callback is needed?

I get the "setState called during build" error if I remove it.

I think in that case the setState isn't necessary either. If the overlay portal and its child get a different BoxConstraints, the overlay child will relayout too. And the layout builder will rebuild. I think that happens in the same frame so it would work better than using a post frame callback.

Hmm it doesn't seem to work when I remove that. When the constraints change, the LayoutBuilder in OverlayPortal.child is called with the new constraints, but the overlayChildBuilder is not called.

I was wrong about using a layout builder. If child gets a different set of constraints, the layout builder callback will be called with the new constraints. But overlay child is laid out using the Overlay's constraints so its layout builder won't be called.

IIRC the Overlay does not give its children unbounded constraints (it should at least be bound by the physical size of the screen). Do you mean a tight height constraint or a loose height constraint?

Loose: 0.0<=h<=Infinity

Without the Positioned widget the constraints are tight to the size of the screen.

Ahhh I see, for positioned children it's not bounded. But why didn't the options view child no like 0.0<=h<=Infinity? Because it's using Align so it doesn't know how to vertically align with infinite amount of vertical space? In that case I guess we have to set Positioned widget's top and bottom to 0

Thanks, that seems to work!

The test that failed has a ListView in the optionsViewBuilder, which I think was the problem.

Use a ValueListenableBuilder instead?

also consider adding an assert to verify the constraints is not unbounded.

Thanks, I forgot ValueListenableBuilder was a thing. Much cleaner.