Move WindowManager outside of WidgetsApp by knopp · Pull Request #188866 · flutter/flutter

knopp · 2026-07-01T15:48:51Z

This is a prototype branch for moving WindowManager outside of WidgetsApp.

Our current approach where first window is "blessed" and other windows are anchored inside first window hierarchy is causing multiple issues:

Only the first window has navigator
Secondary windows focus zones are inside primary window focus zone so it is always focused.
Widget inspector only works in primary window

In general there is no reason for one window to be special. Normally for a desktop application all windows should be equal. The closest we can get to this is to give each top level window its own Widgets/MaterialApp. While this duplicates some elements that should normally be shared, arguably it behaves better than doing what we do right now.

Ideally we'd want to split the App widget into shared and per window parts, but that will be a much bigger change.

With this branch the top level Dialog/Regular window have each their own MaterialApp widget and separate focus trees, solving the issues above.

Popup and Tooltip window work and are anchored at proper place in window hierarchy (they should not be top level window). However we might want to consider a convenience Widget to anchoring these instead of using ViewAnchor + View.

Screenshot of example app running in this mode - notice the Debug banner and widget inspector buttons in each window.

flutter-dashboard · 2026-07-01T15:49:21Z

It looks like this pull request may not have tests. Please make sure to add tests or get an explicit test exemption before merging.

If you are not sure if you need tests, consider this rule of thumb: the purpose of a test is to make sure someone doesn't accidentally revert the fix. Ask yourself, is there anything in your PR that you feel it is important we not accidentally revert back to how it was before your fix?

Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing. If you believe this PR qualifies for a test exemption, contact "@test-exemption-reviewer" in the #hackers channel in Discord (don't just cc them here, they won't see it!). The test exemption team is a small volunteer group, so all reviewers should feel empowered to ask for tests, without delegating that responsibility entirely to the test exemption group.

gemini-code-assist

Code Review

This pull request refactors the windowing system by updating WindowManager to accept a list of initialWindows instead of a single child widget, registering them during initialization, and removing the automatic wrapping of WindowManager in WidgetsApp. The example application is updated accordingly. Feedback on these changes recommends adding documentation for the new initialWindows property, asserting that the list is not empty to prevent widget tree disposal issues, and replacing the forEach loop with a for-in loop for registering windows to adhere to Dart style guidelines.

gemini-code-assist · 2026-07-01T15:51:34Z

  /// {@macro flutter.widgets.windowing.experimental}
  @internal
-  const WindowManager({super.key, required this.child});
+  const WindowManager({super.key, required this.initialWindows});


It is recommended to assert that initialWindows is not empty to prevent creating an empty ViewCollection, which would artificially dispose the widget tree.

Suggested change

const WindowManager({super.key, required this.initialWindows});

const WindowManager({

super.key,

required this.initialWindows,

}) : assert(initialWindows.isNotEmpty, 'initialWindows must not be empty.');

It can be empty.

loic-sharma · 2026-07-01T20:57:46Z

cc @mattkae @loic-sharma @justinmc

mattkae

This seems sensible to me.

Another thing to think about: should the WindowManager just be provided by runWidget long term? That way, it is guaranteed to only show up once at the entry point of the app.

cc: @loic-sharma

mattkae · 2026-07-06T18:02:12Z

+// Disable this for now. This is cursed and only works by accident because
+// the WindowManager was planted in a particular place of WidgetApp hierarchy,
+// which unfortunately caused a host of other issue.
+
+//  final WindowRegistry? windowRegistry = WindowRegistry.maybeOf(context);
+//   if (windowRegistry != null && isWindowingEnabled) {
+//     try {
+//       final Size? parentSize = WindowScope.maybeContentSizeOf(context);
+//       return navigator.push<T>(
+//         _DialogWindowRoute<T>(
+//           builder: builder,
+//           parentController: WindowScope.maybeOf(context),
+//           context: context,
+//           settings: routeSettings,
+//           preferredSize: fullscreenDialog ? parentSize : null,
+//         ),
+//       );
+//     } on UnsupportedError catch (error, stacktrace) {
+//       // Fallback to normal dialog route if windowing is not supported.
+//       FlutterError.reportError(
+//         FlutterErrorDetails(exception: error, library: 'widgets library', stack: stacktrace),
+//       );
+//     }
+//   }


Do we need to disable this for now? Can we just check if the user is manually providing a WindowManager and create the dialog then? I see no harm in that and then we don't need to update the core dialog code at all. It will just mostly do the non-windowy way.

cc: @loic-sharma

The dialog will not be sized to content when it contains entire MaterialApp because the Overlay inside navigator will always size to cosntriants.biggest. So no matter what you do the dialog will cover entire screen. And we have no way to force size using the route.

Possible but hacky solution would be to set the alwaysSizeToContent in navigator overlay if there is WindowManager present. But it's seems really hacky.

I am tempted to keep this code since it still works as good as it did before, but we can also re-add it later if we feel that that is more appropriate 👍

Unfortunately I have to disagree. For the route to work interchangeably with and window windowing enabled the widget would need to be planted at the same place in window hierarchy, but we don't currently have a straightforward way to do that.

gemini-code-assist

Code Review

This pull request refactors window management in Flutter by updating WindowManager to accept a list of initialWindows instead of a single child widget, registering them in initState, and removing windowing-specific dialog routing and WidgetsApp integration. Feedback on these changes suggests adding an assertion to ensure initialWindows is not empty, refactoring Iterable.forEach to a standard for-in loop in _WindowManagerState.initState for better performance and readability, and wrapping the independent widget trees in PopupButton and TooltipButton with MaterialApp or Directionality to prevent runtime errors from missing inherited contexts.

gemini-code-assist · 2026-07-14T14:33:34Z

+            ? View(
+                view: _popupWindowEntry!.controller.rootView,
+                child: Builder(builder: _popupWindowEntry!.builder),
+              )


Since View bootstraps a completely independent widget tree, its child (PopupWindowContent) will not inherit any InheritedWidgets (such as Theme, MediaQuery, or Directionality) from the parent window's context. If PopupWindowContent contains widgets like Text or Material components that rely on these inherited contexts, it will throw runtime errors. Consider wrapping the child in a MaterialApp or at least Directionality and Material to ensure it has the necessary context, similar to how DialogWindowContent and RegularWindowContent were updated.

That is completely incorrect. It's all part of single element tree.

gemini-code-assist · 2026-07-14T14:33:34Z

+            ? View(
+                view: _tooltipEntry!.controller.rootView,
+                child: Builder(builder: _tooltipEntry!.builder),
+              )


Since View bootstraps a completely independent widget tree, its child (TooltipWindowContent) will not inherit any InheritedWidgets (such as Theme, MediaQuery, or Directionality) from the parent window's context. If TooltipWindowContent contains widgets like Text or Material components that rely on these inherited contexts, it will throw runtime errors. Consider wrapping the child in a MaterialApp or at least Directionality and Material to ensure it has the necessary context, similar to how DialogWindowContent and RegularWindowContent were updated.

Nope. See above.

gemini-code-assist · 2026-07-14T14:33:34Z

-    }
+  void initState() {
+    super.initState();
+    widget.initialWindows.forEach(_registry.register);


In Flutter framework code, using a standard for loop is preferred over Iterable.forEach for better readability and to avoid the overhead of function closures. Consider refactoring this to a standard for-in loop.

for (final WindowEntry entry in widget.initialWindows) { _registry.register(entry); }

References

Effective Dart recommends avoiding Iterable.forEach with function literals or when a standard for loop is more readable and performant. ^(link)

No. Using normal for loop actually triggers analyzer warning.

flutter-dashboard Bot added the CICD Run CI/CD label Jul 1, 2026

github-actions Bot added framework flutter/packages/flutter repository. See also f: labels. d: examples Sample code and demos labels Jul 1, 2026

knopp marked this pull request as draft July 1, 2026 15:49

gemini-code-assist Bot reviewed Jul 1, 2026

View reviewed changes

knopp mentioned this pull request Jul 1, 2026

[Windows] Keep regular windows in place when another is activated #188016

Merged

10 tasks

mattkae previously approved these changes Jul 6, 2026

View reviewed changes

knopp added 3 commits July 14, 2026 15:43

Move WindowManager outside of WidgetsApp.

62cc87c

Get popup and tooltip working.

9ea581d

Nope.

4560628

knopp dismissed mattkae’s stale review via 4560628 July 14, 2026 13:45

knopp force-pushed the move_window_manager_out branch from bcf20cb to 4560628 Compare July 14, 2026 13:45

knopp added 3 commits July 14, 2026 15:51

Feedback.

99d3610

Reformat

4823bb6

Fix

0865228

github-actions Bot added d: api docs Issues with https://api.flutter.dev/ a: desktop Running on desktop labels Jul 14, 2026

Remove unused imports

c08b10e

knopp marked this pull request as ready for review July 14, 2026 14:31

gemini-code-assist Bot reviewed Jul 14, 2026

View reviewed changes

mattkae approved these changes Jul 23, 2026

View reviewed changes

knopp added this pull request to the merge queue Jul 23, 2026

Merged via the queue into flutter:master with commit 22fcba1 Jul 23, 2026
86 of 87 checks passed

knopp deleted the move_window_manager_out branch July 23, 2026 15:33

This was referenced Jul 23, 2026

Roll Flutter from 2a2a79d36624 to 22fcba1c30a8 (16 revisions) flutter/packages#12278

Closed

Roll Flutter from 2a2a79d36624 to c3f6236f61f5 (17 revisions) flutter/packages#12279

Closed

Uh oh!

Conversation

knopp commented Jul 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

flutter-dashboard Bot commented Jul 1, 2026

Uh oh!

gemini-code-assist Bot left a comment

Choose a reason for hiding this comment

Code Review

Uh oh!

Uh oh!

gemini-code-assist Bot Jul 1, 2026

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

loic-sharma commented Jul 1, 2026

Uh oh!

mattkae left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist Bot left a comment

Choose a reason for hiding this comment

Code Review

Uh oh!

gemini-code-assist Bot Jul 14, 2026

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist Bot Jul 14, 2026

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

gemini-code-assist Bot Jul 14, 2026

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

knopp commented Jul 1, 2026 •

edited

Loading