Closing a `RawMenuAnchor` now triggers the `onCloseRequested` and `onClose` callbacks for all descendant `RawMenuAnchor`s. The `onCloseRequested` callback is triggered top-down, starting from the triggering `RawMenuAnchor` and moving to its descendants, while the `onClose` callback is triggered bottom-up. If a `RawMenuAnchor` is already closed, calls to `MenuController.close` and `MenuController.closeChildren` don't trigger the `onCloseRequested` callback.
- Who is affected
- Applications and packages relying on the previous behaviour or signature. Code that uses RawMenuAnchor, MenuController.close, MenuController.closeChildren and related APIs.
- Practical impact
- Behaviour or API differences that can break builds or change runtime behaviour.
- What action should I take?
- Follow the official migration guide below, update affected call sites, run `dart fix --apply` where a fix is available, then run your tests.
Before and after (from the official guide)
| 1 | RawMenuAnchor( | |
| 2 | controller: menuController, | |
| 3 | onCloseRequested: (hideOverlay) { | |
| 4 | if (!animationController.isForwardOrCompleted) { | |
| 5 | return; | |
| 6 | } | |
| 7 | ||
| 8 | − | // Descendant submenus must be closed before the parent menu. |
| 9 | − | // This is now handled automatically, so this call is no longer necessary. |
| 10 | − | menuController.closeChildren(); |
| 11 | animationController.reverse().whenComplete(hideOverlay); | |
| 12 | }, | |
| 13 | onClose: () { | |
| 14 | − | // This might have executed before descendants called onClose(). |
| 15 | _handleMenuClosed(); | |
| 16 | }, | |
| 17 | // ... | |
| 18 | ) |
| 1 | RawMenuAnchor( | |
| 2 | controller: menuController, | |
| 3 | onCloseRequested: (hideOverlay) { | |
| 4 | if (!animationController.isForwardOrCompleted) { | |
| 5 | return; | |
| 6 | } | |
| 7 | ||
| 8 | + | // `menuController.closeChildren()` is now called automatically. |
| 9 | animationController.reverse().whenComplete(hideOverlay); | |
| 10 | }, | |
| 11 | onClose: () { | |
| 12 | + | // This now executes only after all descendant submenus have |
| 13 | + | // called `onClose()`. |
| 14 | _handleMenuClosed(); | |
| 15 | }, | |
| 16 | // ... | |
| 17 | ) |
Raw before / after
RawMenuAnchor(
controller: menuController,
onCloseRequested: (hideOverlay) {
if (!animationController.isForwardOrCompleted) {
return;
}
// Descendant submenus must be closed before the parent menu.
// This is now handled automatically, so this call is no longer necessary.
menuController.closeChildren();
animationController.reverse().whenComplete(hideOverlay);
},
onClose: () {
// This might have executed before descendants called onClose().
_handleMenuClosed();
},
// ...
)RawMenuAnchor(
controller: menuController,
onCloseRequested: (hideOverlay) {
if (!animationController.isForwardOrCompleted) {
return;
}
// `menuController.closeChildren()` is now called automatically.
animationController.reverse().whenComplete(hideOverlay);
},
onClose: () {
// This now executes only after all descendant submenus have
// called `onClose()`.
_handleMenuClosed();
},
// ...
)Official migration guide (excerpt, © The Flutter Authors, CC BY 3.0)
If your code does not override the default implementation of
RawMenuAnchor.onCloseRequested or your RawMenuAnchor
does not contain submenus, no changes are required.
If you have a custom implementation of onCloseRequested
in a RawMenuAnchor containing submenus,
controller.closeChildren() is now called automatically
when the parent menu closes.
Make sure that your implementation of onCloseRequested
still behaves correctly with this automatic call.
Immediate calls to controller.closeChildren() within your
onCloseRequested callback are no longer necessary.
Remove those calls.
Additionally, if your logic relied on the
parent's onClose callback firing before its descendants,
refactor your code to account for the new bottom-up execution order.
Code before migration:
RawMenuAnchor(
controller: menuController,
onCloseRequested: (hideOverlay) {
if (!animationController.isForwardOrCompleted) {
return;
}
// Descendant submenus must be closed before the parent menu.
// This is now handled automatically, so this call is no longer necessary.
menuController.closeChildren();
animationController.reverse().whenComplete(hideOverlay);
},
onClose: () {
// This might have executed before descendants called onClose().
_handleMenuClosed();
},
// ...
)Code after migration:
RawMenuAnchor(
controller: menuController,
onCloseRequested: (hideOverlay) {
if (!animationController.isForwardOrCompleted) {
return;
}
// `menuController.closeChildren()` is now called automatically.
animationController.reverse().whenComplete(hideOverlay);
},
onClose: () {
// This now executes only after all descendant submenus have
// called `onClose()`.
_handleMenuClosed();
},
// ...
)Landed in version: 3.44.0-0.1.pre In stable release: 3.44
AI_PROVIDER (for example to openai-compatible with a local Ollama or LM Studio endpoint) to enable grounded explanations. Everything else on this page works without an AI provider.Listed in the official breaking-changes index (docs.flutter.dev/release/breaking-changes).
An official announcement or migration guide documents an intended behaviour or API change. A verified source change (git diff) shows code changed but does not by itself prove a public API is breaking. AI interpretations are labelled and never used to classify a change.
- Source commit
- b3045439b7c0
- Source last updated
- Oct 21, 2026
- Last synchronized
- Oct 21, 2026
- Publication status
- published
Publication history
- Oct 21, 2026, 8:31 PM: new → published (ingestion) — Backed by an official breaking-change/migration guide.
AI_PROVIDER (for example to openai-compatible with a local Ollama or LM Studio endpoint) to enable grounded explanations. Everything else on this page works without an AI provider.