SchedulerBinding.instance.addPostFrameCallback((Duration timestamp) {
      if (!mounted || !_overlayController.isShowing) {
        return;
      }
      if (info != _getRawMenuOverlayInfo(context)) {
        // Rebuild overlayBuilder
        _overlayController.hide();
        _overlayController.show();
      }
    });

Somehow being callback inside build method, I am not feeling good + the way I am rebuilding overlay. I would love to hear feedback, how we can achieve this otherwise.

@davidhicks980 Would you like to take a look? (I wonder why you proposed the LayerLink solution in the original issue instead of this)

@dkwingsmt:

Addressing @Piinks' point, the post-frame callback causes a single-frame stutter. To @chunhtai's point, you can use leader/follower for single-layer menus, but:

• You won't have access to the latest position.
• Transforming widgets in nested compositing layers can break hit testing (at some point I need to file an issue regarding this).

AFAIK, the whole reason why the menu was programmed to close on scroll/resize is because the position doesn't update.

That said, @LongCatIsLooong just landed OverlayPortal.overlayChildLayoutBuilder, which may be the best solution we have. However, this constructor does not allow the root overlay to be used, which would be a breaking change for current users of RawMenuAnchor. Also, OverlayPortal.overlayChildLayoutBuilder cannot be used with leader/follower layers (

To add support for the root overlay, I proposed making the _OverlayChildLayoutBuilder callback widget (returned by OverlayPortal.overlayChildLayoutBuilder) public so that it can be used with both OverlayPortal and OverlayPortal.targetsRootOverlay (#168785 (comment)). If I have the go-ahead, I'll try that. I'm not sure if there are any problems with this approach, but this would be most the most flexible solution.

Hope that makes sense! I wrote this in the main thread so that it wouldn't get buried.

We expect we'll be able to come back to this next week due to some of us being OOO, thanks @rkishan516 for the patience.

is this only needed for first build? or is this meant to track the anchor movement over the life time of this overlay entry?

No, its required for every position change for anchor.

it is the latter, why do we check ONLY one frame? what if the anchor move after two frames?

Because just after position of anchor is decided, immediate post frame callback we can utilize it to render overlay entry at correct position.

if anchor moves after n frame, then postFramecallback will be called after that frame is rendered.

@chunhtai I'm also not sure if there are layout complications with the root overlay...

A drawback to the boolean approach is that OverlayPortal derivatives, such as RawMenuAnchor, MenuAnchor, and CupertinoMenuAnchor, would need two booleans (useRootOverlay and useOverlayChildLayoutBuilder). If we just exposed _OverlayChildLayoutBuilder, no API changes on OverlayPortal derivatives would need to be made to allow users to observe changes. That said, there could be some major limitation I'm not aware of...

if anchor moves after n frame, then postFramecallback will be called after that frame is rendered.

the postframecallback will only be called once after the build is called. Do we have code path that triggers the build to be called again after the anchor is moved?

OverlayPortal derivatives, such as RawMenuAnchor, MenuAnchor, and CupertinoMenuAnchor, would need two booleans (useRootOverlay and useOverlayChildLayoutBuilder).

Why do we need useOverlayChildLayoutBuilder? I am more leaning toward adding a boolean for
OverlayPortal.overlayChildLayoutBuilder(useRootOverlay:) and call it a day. I am uncomfortable with opening up _OverlayChildLayoutBuilder since we will be exposing implementation detail to maintain. Looking at the class, it contains some complex logic to make it work.

the postframecallback will only be called once after the build is called. Do we have code path that triggers the build to be called again after the anchor is moved?

Yes, we are calling overlayController.show in postFrameCallback which ends up building overlay.

the postframecallback will only be called once after the build is called. Do we have code path that triggers the build to be called again after the anchor is moved?

Yes, we are calling overlayController.show in postFrameCallback which ends up building overlay.

What I meant was that the anchor box change after the first frame will not notify the overlay to re-calculate the rect. For example

class CustomPadding extends StatefulWidget {
  @override
  State<StatefulWidget> createState() => CustomPaddingState();
}

class CustomPaddingState extends State<CustomPadding> {
  double left = 0;

  void setPadding(double newLeft) {
    setState(() {
      left = newLeft;
    });
  }

  @override
  Widget build(BuildContext context) {
    return Padding(
      padding: EdgeInsetsGeometry.only(left: left),
      child: const AnchorButton(Tag.anchor),
    );
  }
}


  testWidgets("test", (WidgetTester tester) async {
    Rect? anchorRect;
    await tester.pumpWidget(
      App(
        RawMenuAnchor(
          controller: controller,
          overlayBuilder: (BuildContext context, RawMenuOverlayInfo position) {
            anchorRect = position.anchorRect;
            return Panel(children: <Widget>[Text(Tag.a.text)]);
          },
          child: CustomPadding(),
        ),
      ),
    );

    await tester.tap(find.text(Tag.anchor.text));
    await tester.pump();

    expect(controller.isOpen, isTrue);
    expect(find.text(Tag.a.text), findsOneWidget);

    final CustomPaddingState state = tester.state<CustomPaddingState>(find.byType(CustomPadding));
    final RenderBox anchorBox = state.context.findRenderObject()! as RenderBox;
    ui.Offset upperLeft = anchorBox.localToGlobal(Offset.zero);
    ui.Offset bottomRight = anchorBox.localToGlobal(anchorBox.size.bottomRight(Offset.zero));
    expect(anchorRect, Rect.fromPoints(upperLeft, bottomRight));

    /// Shift the box to the right by 10
    state.setPadding(10);
    await tester.pumpAndSettle();
    await tester.pumpAndSettle();
    await tester.pumpAndSettle();
    await tester.pumpAndSettle();

    upperLeft = anchorBox.localToGlobal(Offset.zero);
    bottomRight = anchorBox.localToGlobal(anchorBox.size.bottomRight(Offset.zero));
    expect(anchorRect, Rect.fromPoints(upperLeft, bottomRight)); // This failed
  });

@chunhtai This example doesn't exactly match, how _buildOverlay is working.

1. Some change happens on anchor may be anchor is marked as dirty
2. anchor then call overlayChildBuilder (at this point we don't have correct information of rect)
3. overlayChildBuilder i.e. _buildOverlay method of us, it return widget.overlayBuilder but also schedule a callback when frame is rendered
4. When frame is rendered, scheduled callback is now called and now we have correct information for rect

Step3 schedule of callback happens every time _buildOverlay is called. It's not dependent on first frame.

@chunhtai That's a good catch. There will be situations where the anchor may move following the first frame.

An example for visually confirming:

import 'package:flutter/widgets.dart' hide MenuController, RawMenuAnchor, RawMenuOverlayInfo;

import 'new_raw_menu_anchor.dart';

void main() {
  runApp(const GoodCatch());
}

class GoodCatch extends StatefulWidget {
  const GoodCatch({super.key});

  @override
  State<StatefulWidget> createState() => GoodCatchState();
}

class GoodCatchState extends State<GoodCatch> with TickerProviderStateMixin {
  double left = 10;
  MenuController controller = MenuController();
  AnimationController? animationController;

  @override
  void initState() {
    super.initState();
    animationController = AnimationController(
      duration: const Duration(milliseconds: 300),
      vsync: this,
    );
    Future<void>.delayed(const Duration(milliseconds: 100), controller.open);
    Future<void>.delayed(const Duration(seconds: 1), () {
      animationController?.repeat(reverse: true);
    });
  }

  @override
  Widget build(BuildContext context) {
    return Directionality(
      textDirection: TextDirection.ltr,
      child: Overlay(
        initialEntries: <OverlayEntry>[
          OverlayEntry(
            builder: (BuildContext context) {
              return Align(
                child: RawMenuAnchor(
                  controller: controller,
                  overlayBuilder: (BuildContext context, RawMenuOverlayInfo info) {
                    return Positioned.fromRect(
                      rect: info.anchorRect.shift(const Offset(0, 50)),
                      child: const ColoredBox(
                        color: Color(0xFFFF00FF),
                        child: Text('Not jiggy with it :('),
                      ),
                    );
                  },
                  builder: (BuildContext context, MenuController controller, Widget? child) {
                    return AnimatedBuilder(
                      animation: animationController!,
                      builder: (BuildContext context, Widget? child) {
                        return Padding(
                          padding: EdgeInsets.only(left: left * animationController!.value),
                          child: child,
                        );
                      },
                      child: const ColoredBox(
                        color: Color(0xFF0F00F0),
                        child: Text("Gettin' jiggy with it"),
                      ),
                    );
                  },
                ),
              );
            },
          ),
        ],
      ),
    );
  }
}

The current solution won't catch all the corner cases, and using postframe callback in build method has potential to cause unending rebuilds, which is quite dangerous

For example, if (info != _getRawMenuOverlayInfo(context)) can cause trouble if there is floating point precision error. It would be good that if we have some way of react to size change instead of polling.

I am currently working on #168785 hopefully this can give a way to solve this problem

For example, if (info != _getRawMenuOverlayInfo(context)) can cause trouble if there is floating point precision error. It would be good that if we have some way of react to size change instead of polling.

Yes, that's what my concern was with this.

Okay, I will wait for #168785.

@rkishan516 FYI it looks like the issue this was waiting on (#168785) has been closed as completed.

@rkishan516 FYI it looks like the issue this was waiting on (#168785) has been closed as completed.

Thanks for reminder @justinmc, I have updated implementation.

@LongCatIsLooong Just to verify, does it matter that MenuAnchor allows for the use of CompositedTransformFollower?

Curious because of this line

@LongCatIsLooong Just to verify, does it matter that MenuAnchor allows for the use of CompositedTransformFollower?

flutter/packages/flutter/lib/src/material/menu_anchor.dart

Lines 3427 to 3431 in c18530c

	return CompositedTransformFollower(
	link: layerLink!,
	targetAnchor: Alignment.bottomLeft,
	child: layout,
	);

Curious because of this line

You'll get an assertion in debug mode if an OverlayPortal with overlayChildLayoutBuilder is in a CompositedTransformFollower. So if the layout widget here has an OverlayPortal.overlayChildLayoutBuilder in it it will probably throw. (also feel free to update the documentation if it can be made more clear).

@LongCatIsLooong That makes sense and your doc makes sense. My main concern is existing apps which implement something like the following will now assert in debug:

void main() {
  runApp(const OverlayTest());
}

class OverlayTest extends StatelessWidget {
  const OverlayTest({super.key});

  @override
  Widget build(BuildContext context) {
    return Directionality(
      textDirection: TextDirection.ltr,
      child: MaterialApp(
        home: Column(
          children: <Widget>[
            MenuAnchor(
              layerLink: LayerLink(),
              builder: (BuildContext context, MenuController controller, Widget? child) {
                return ElevatedButton(
                  onPressed: () {
                    if (controller.isOpen) {
                      controller.close();
                    } else {
                      controller.open();
                    }
                  },
                  child: const Text('Show Menu'),
                );
              },
              menuChildren: const <Widget>[
                SubmenuButton(
                  menuChildren: <Widget>[
                    SizedBox()
                  ],
                  child: Text('Submenu'),
                ),
              ],
            ),
          ],
        ),
      ),
    );
  }
}

Not technically breaking since no tests are broken, but we may want to deprecate the LayerLink at some point in the future.