Automatically handle back gesture in nested Navigators by justinmc · Pull Request #152330 · flutter/flutter

justinmc · 2024-07-25T17:41:08Z

There is a known problem with using nested Navigator widgets in Flutter. System back events will still go to the root Navigator instead of the nested one. The solution has been to use WillPopScope (and later PopScope/NavigatorPopHandler) to catch the system back and handle it manually. See the docs on NavigatorPopHandler for more on this problem and how we recommend solving it.

This PR is exploring the idea: why doesn't Flutter handle this complexity automatically for users? The navigation scenarios may be varied enough that Flutter can't solve this automatically without breaking some of them, but I hope to find out if that's true.

Fixes #145290
Fixes #153672

Discovered while working on this: #152578

Multiple nested Navigators

I thought this would require more work, but it seems maybePop correctly doesn't pop the inactive Navigator.

Multiple nested Navigators example

import 'package:flutter/material.dart';

void main() async {
  runApp(const _MyApp());
}

class _MyApp extends StatelessWidget {
  const _MyApp();

  // This widget is the root of your application.
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      theme: ThemeData(
        useMaterial3: false,
        /*
        pageTransitionsTheme: const PageTransitionsTheme(
          builders: <TargetPlatform, PageTransitionsBuilder>{
            TargetPlatform.android: PredictiveBackPageTransitionsBuilder(),
          },
        ),
        */
      ),
      title: 'Flutter Demo',
      routes: {
        '/': (BuildContext context) {
          return _MyNestedNavigator();
        },
        'nav1leaf': (BuildContext context) {
          return const Nav1LeafPage();
        },
      },
    );
  }
}

class _MyNestedNavigator extends StatelessWidget {
  _MyNestedNavigator();

  final GlobalKey<NavigatorState> _nestedNavigatorKey = GlobalKey<NavigatorState>();

  @override
  Widget build(BuildContext context) {
    return Navigator(
      key: _nestedNavigatorKey,
      initialRoute: 'nav2home',
      onGenerateRoute: (RouteSettings settings) {
        return switch (settings.name) {
          'nav2home' => MaterialPageRoute(
            builder: (BuildContext context) => const MyHomePage(),
          ),
          'nav2leaf' => MaterialPageRoute(
            builder: (BuildContext context) => const Nav2LeafPage(),
          ),
          'nav3' => MaterialPageRoute(
            builder: (BuildContext context) => _MyNestedNestedNavigator(),
          ),
          _ => MaterialPageRoute(
            builder: (BuildContext context) => const Text('404'),
          ),
        };
      },
    );
  }
}

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

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      backgroundColor: Colors.blueAccent,
      body: Center(
        child: Column(
          mainAxisAlignment: MainAxisAlignment.center,
          children: <Widget>[
            const Text('Home page of Navigator 2'),
            const SizedBox(height: 16, width: double.infinity),
            ElevatedButton(
              child: const Text('Open nav 2 leaf'),
              onPressed: () => Navigator.of(context).pushNamed('nav2leaf'),
            ),
          ],
        ),
      ),
    );
  }
}

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

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      backgroundColor: Colors.blue,
      body: Column(
        mainAxisAlignment: MainAxisAlignment.center,
        crossAxisAlignment: CrossAxisAlignment.center,
        children: [
          const Text('Leaf page of Navigator 2'),
          const SizedBox(height: 16, width: double.infinity),
          ElevatedButton(
            child: const Text('Open nav 3 home'),
            onPressed: () => Navigator.of(context).pushNamed('nav3'),
          ),
          const SizedBox(height: 16, width: double.infinity),
          ElevatedButton(
            child: const Text('Open nav 1 leaf'),
            onPressed: () => Navigator.of(context, rootNavigator: true).pushNamed('nav1leaf'),
          ),
        ],
      ),
    );
  }
}

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

  @override
  Widget build(BuildContext context) {
    return const Scaffold(
      body: Column(
        mainAxisAlignment: MainAxisAlignment.center,
        crossAxisAlignment: CrossAxisAlignment.center,
        children: [
          Text('Leaf of Navigator 1'),
        ],
      ),
    );
  }
}

class _MyNestedNestedNavigator extends StatelessWidget {
  _MyNestedNestedNavigator();

  final GlobalKey<NavigatorState> _nestedNavigatorKey = GlobalKey<NavigatorState>();

  @override
  Widget build(BuildContext context) {
    return Navigator(
      key: _nestedNavigatorKey,
      initialRoute: 'nav3home',
      onGenerateRoute: (RouteSettings settings) {
        return switch (settings.name) {
          'nav3home' => MaterialPageRoute(
            builder: (BuildContext context) => const NestedNestedNavigatorHomePage(),
          ),
          'nav3leaf' => MaterialPageRoute(
            builder: (BuildContext context) => const Nav3LeafPage(),
          ),
          _ => MaterialPageRoute(
            builder: (BuildContext context) => const Text('404'),
          ),
        };
      },
    );
  }
}

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

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      backgroundColor: Colors.amber,
      body: Center(
        child: Column(
          mainAxisAlignment: MainAxisAlignment.center,
          children: <Widget>[
            const Text('Home page of Navigator 3'),
            const SizedBox(height: 16, width: double.infinity),
            ElevatedButton(
              child: const Text('Open nav 3 leaf'),
              onPressed: () => Navigator.of(context).pushNamed('nav3leaf'),
            ),
          ],
        ),
      ),
    );
  }
}

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

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      backgroundColor: Colors.amberAccent,
      body: Column(
        mainAxisAlignment: MainAxisAlignment.center,
        crossAxisAlignment: CrossAxisAlignment.center,
        children: [
          const Text('Leaf page of Navigator 3'),
          const SizedBox(height: 16, width: double.infinity),
          ElevatedButton(
            child: const Text('Open nav 1 leaf'),
            onPressed: () => Navigator.of(context, rootNavigator: true).pushNamed('nav1leaf'),
          ),
        ],
      ),
    );
  }
}

TODO

More tests, if it looks like this PR is viable.

…or widgets

flutter-dashboard · 2024-07-25T17:41:11Z

It looks like this pull request may not have tests. Please make sure to add tests before merging. If you need an exemption to this rule, contact "@test-exemption-reviewer" in the #hackers channel in Chat (don't just cc them here, they won't see it! Use Discord!).

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.

… active The tabs are not managed by routes, they are just shown and hidden, so this widget needs special custom handling of backs. This is a good example of when we can't do this automatically.

They don't need to do PopScope themselves anymore.

…ons do work Red herring, it only happens in complex interleaving scenarios, and that is a bug in master too.

justinmc · 2024-07-31T17:00:41Z

@maRci002 I'm interested in your thoughts here if you have a chance to take a look.

chunhtai · 2024-07-31T16:45:33Z

+
+    // If this is a nested Navigator, handle system backs here so that the root
+    // Navigator doesn't get all of them.
+    if (widget.handlesBacksWhenNested && Navigator.maybeOf(context, rootNavigator: true) != this) {


Navigator.maybeOf may be costly in this situation since this will walk ancestor chain every rebuild, I will probably put the check in didChangeDependencies

chunhtai · 2024-07-31T17:01:26Z

+      // Manually use a NavigatorPopHandler to handle backs only on the active
+      // tab, instead of letting Navigator use its default back handling for
+      // nested Navigators.
+      handlesBacksWhenNested: false,


This is unfortunate. if there are multiple parallel navigators, what decide which one receives the pop?

See this test for how tabbed navigation is typically done here:

flutter/packages/flutter/test/cupertino/tab_scaffold_test.dart

Line 1274 in 8d3d3ee

testWidgets('System back navigation inside of tabs', (WidgetTester tester) async {

Each tab has its own nested Navigator wrapped by NavigatorPopHandler. Only the single active tab's NavigatorPopHandler is enabled though, so it's the only one that receives a call to onPop.

Or for the more generic case, where you have 2 sibling Navigators each wrapped with a PopScope, and both nested under a root Navigator? Both will be called. I think that's probably what we want.

flutter/packages/flutter/lib/src/widgets/routes.dart

Line 1788 in 8d3d3ee

void onPopInvokedWithResult(bool didPop, T? result) {

But for the even more generic case where you have two WidgetsBindingObservers listening for didPopRoute, only the one that was registered first will be called. I think that's very arbitrary and probably a mistake. It would probably solve a lot of the complexity with PopScope etc. if it was able to just call it on the current route or something.

flutter/packages/flutter/lib/src/widgets/binding.dart

Line 859 in 8d3d3ee

Future<bool> handlePopRoute() async {

@chunhtai I wonder what you think about this handlesBacksWhenNested parameter versus scrapping this PR and adding NavigatorPopHandler to go_router?

I think the current approach of adding this parameter may be easier for developer

maRci002 · 2024-08-01T09:19:49Z

Here are some contexts for managing the back button in Flutter:

Using Back Button (without predictive back):

WidgetsBinding.handlePopRoute is invoked at very first

flutter/packages/flutter/lib/src/widgets/binding.dart

Lines 833 to 840 in b0850be

    
           Future<void> handlePopRoute() async { 
        
             for (final WidgetsBindingObserver observer in List<WidgetsBindingObserver>.of(_observers)) { 
        
               if (await observer.didPopRoute()) { 
        
                 return; 
        
               } 
        
             } 
        
             SystemNavigator.pop(); 
        
           }

Non-router version:

_WidgetsAppState.didPopRoute is invoked.

flutter/packages/flutter/lib/src/widgets/app.dart

Lines 1537 to 1552 in b0850be

    
           // On Android: the user has pressed the back button. 
        
           @override 
        
           Future<bool> didPopRoute() async { 
        
             assert(mounted); 
        
             // The back button dispatcher should handle the pop route if we use a 
        
             // router. 
        
             if (_usesRouterWithDelegates) { 
        
               return false; 
        
             } 
        
             final NavigatorState? navigator = _navigator?.currentState; 
        
             if (navigator == null) { 
        
               return false; 
        
             } 
        
             return navigator.maybePop(); 
        
           }

If you need to delegate the back button to a nested Navigator, use the techniques outlined in this documentation on migrating from WillPopScope to NavigatorPopHandler for nested navigators.

Router version:
- RootBackButtonDispatcher.didPopRoute is triggered
  
  flutter/packages/flutter/lib/src/widgets/router.dart
  
  Line 1073 in b0850be
  
  Future<bool> didPopRoute() => invokeCallback(Future<bool>.value(false));
- To delegate the back button to a nested Navigator, you should override RouterDelegate.popRoute. Depending on your AppState (which should know which Navigator is active, e.g., when a BottomNavigationBar is used where each tab has its own Navigator), find the appropriate NavigatorState by GlobalKey and call pop / maybePop on it.
  
  flutter/packages/flutter/lib/src/widgets/router.dart
  
  Line 1352 in b0850be
  
  Future<bool> popRoute();

Using Predictive Back:

The following methods manage predictive back actions: WidgetsBinding._handleStartBackGesture / _handleUpdateBackGestureProgress / _handleCommitBackGesture / _handleCancelBackGesture.

The method _handleStartBackGesture sets the _backGestureObserver, which handles the rest of the predictive back actions

flutter/packages/flutter/lib/src/widgets/binding.dart

Lines 845 to 855 in b0850be

    
           Future<bool> _handleStartBackGesture(Map<String?, Object?> arguments) { 
        
             _backGestureObserver = null; 
        
             final PredictiveBackEvent backEvent = PredictiveBackEvent.fromMap(arguments); 
        
             for (final WidgetsBindingObserver observer in List<WidgetsBindingObserver>.of(_observers)) { 
        
               if (observer.handleStartBackGesture(backEvent)) { 
        
                 _backGestureObserver = observer; 
        
                 return Future<bool>.value(true); 
        
               } 
        
             } 
        
             return Future<bool>.value(false); 
        
           }

Currently, we can delegate the back button to the appropriate Navigator, but we cannot delegate predictive back events to the appropriate Navigator. This pull request also aims to handle back button delegations?

I am unsure whether the current solution is capable of determining which Navigator should handle system gestures, since we are registering WidgetsBindingObservers in order. This means that MaterialApp / RootBackButtonDispatcher will always have priority over system gestures

flutter/packages/flutter/lib/src/widgets/binding.dart

Line 693 in b0850be

void addObserver(WidgetsBindingObserver observer) => _observers.add(observer);

The solution has been to use WillPopScope (and later PopScope/NavigatorPopHandler) to catch the system back and handle it manually.

I believe the approach is good and we shouldn't break it.

We might need a flag on the Navigator, like handlesPredictiveBack, and _PredictiveBackGestureDetectorState._isEnabled could also check for this with route.navigator?.widget.handlesPredictiveBack, and that’s it. This value could be true by default, so we don’t disrupt existing functionality, and we could add this flag to MaterialApp's constructor to proxy the value to Navigator.

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

Lines 88 to 92 in b0850be

    
             /// True when the predictive back gesture is enabled. 
        
             bool get _isEnabled { 
        
               return widget.route.isCurrent 
        
                   && widget.route.popGestureEnabled; 
        
             }

…ions_builder.dart Co-authored-by: chunhtai <[email protected]>

justinmc · 2024-08-02T23:36:43Z

@maRci002 What would that flag do?

This PR was not attempting to fix the problem with predictive back route transitions.

I'm just realizing that this PR does not fix the problem with ShellRoute either! Because go_router does not have a root Navigator. I need to reproduce that problem with just MaterialApp.router and no go_router so I fully understand it.

justinmc · 2025-09-16T18:07:17Z

@chunhtai This is finally ready for re-review. I was worried that this PR would be too breaking, but now go_router’s breakages are fixed, the failing Google tests are very minimal (and I have a g3fix), and there are no customer test failures. I think I’m confident enough to try merging this. It should be much easier for users in the majority of cases, where they don’t want to think about handling predictive back gestures manually for their nested Navigators.

chunhtai · 2025-09-23T18:27:41Z

+  ///  * [PopScope], which provides even more control over system back behavior.
+  ///  * [CupertinoTabView], which sets this parameter to false in order to
+  ///    provide custom back handling for its nested [Navigator]s.
+  final bool handlesBacksWhenNested;


Just a thought, should this be tristate to make things easier? in case of null, it automatically check whether this is nested by calling Navigator.of

That's what true does currently, see _isRootNavigator and _getIsRootNavigator.

I think there is really no third state to be handled. When the Navigator is not root, then it doesn't need a PopScope widget, it will handle back gestures anyway. So an unqualified handlesBacks set to true would mean the same thing as handlesBacksWhenNested is true. And it's not really possible to not handle backs at all for a root Navigator.

Maybe the "WhenNested" part of the name makes this confusing.

chunhtai · 2025-09-23T18:29:19Z

+  late bool _isRootNavigator;
+
+  bool _lastCanPopCached = false; // Because history is empty to start.
+  bool get _lastCanPop => _lastCanPopCached;


consider move the _lastCanPopCached into the middle
getter
private property
setter

chunhtai · 2025-09-23T18:30:43Z

+    // If this Navigator handles back gestures, then rebuild when canPop changes
+    // so that the PopScope can be updated.
+    if (_handlesBackGestures && value != _lastCanPop) {
+      ServicesBinding.instance.addPostFrameCallback((Duration timestamp) {


we should check for schedule phase I image we may not always changeing this in build state in the future

chunhtai · 2025-09-23T18:31:49Z

+
+  // If this is a nested Navigator, handle system backs so that the root
+  // Navigator doesn't get all of them.
+  bool get _handlesBackGestures => widget.handlesBacksWhenNested && !_isRootNavigator;


If we are checking _isRootNavigator, does the root navigator need to set this to false?

The root navigator itself will have _isRootNavigator set to false, so _handlesBackGestures will always be false for the root navigator. So it doesn't matter what handlesBackWhenNested is for the root navigator.

Does that answer your question? Maybe the naming makes this confusing...

in that case, I don't think we need to set handlesBackWhenNested: false in WidgetsApp

chunhtai · 2025-09-23T19:17:07Z

+
+  bool _lastCanPopCached = false; // Because history is empty to start.
+  bool get _lastCanPop => _lastCanPopCached;
+  set _lastCanPop(bool value) {


not something need to be addressed now. we now has canPop, _lastCanPop, feels a bit weird. and when to use which in the navigatorState. Consider consolidate them (maybe a breaking change or deprcating canPop()) and turn them into changenotifier

Good point. I'll add a comment here to help explain lastCanPop in the meantime.

chunhtai · 2025-09-23T19:18:49Z

+    // Navigator doesn't get all of them.
+    if (widget.handlesBacksWhenNested && Navigator.maybeOf(context, rootNavigator: true) != this) {
+      return PopScope(
+        canPop: !canPop(),


Can you add a comment here says rebuild will be triggered when _lastCanPop changed

chunhtai

LGTM, just one suggestion

chunhtai · 2025-09-29T20:13:45Z

        debugLabel: 'Navigator Scope',
        autofocus: true,
        child: Navigator(
+          handlesBacksWhenNested: false,


This is not needed since handlesBacksWhenNested: true can still handle the root case. While uncommon, but I have seen people doing MaterialApp inside a MaterialApp...

I think I did this specifically to work around a weird setup like that in the Google tests. I will try it and see if it passes, maybe that's out of date or I'm misremembering.

chunhtai · 2025-09-29T20:14:41Z

+
+  // If this is a nested Navigator, handle system backs so that the root
+  // Navigator doesn't get all of them.
+  bool get _handlesBackGestures => widget.handlesBacksWhenNested && !_isRootNavigator;


in that case, I don't think we need to set handlesBackWhenNested: false in WidgetsApp

Piinks · 2025-12-08T22:47:51Z

Greetings from stale PR triage! 👋
Is this change still on your radar?

flutter-dashboard · 2026-03-25T18:25:16Z

This pull request has been changed to a draft. The currently pending flutter-gold status will not be able to resolve until a new commit is pushed or the change is marked ready for review again.

For more guidance, visit Writing a golden file test for package:flutter.

Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing.

This test was failing in flutter/flutter#152330. That PR adds a PopScope inside of nested Navigators. When a back gesture happens, the PopScope takes 1 frame to rerender and update the state of its pop handling. The test was breaking because it performed two back gestures in one frame. Putting a pump in between them fixes it when the PR is merged (and works fine without the PR too). It took me so many hours to realize this one little pump was the fix I needed 😭 .

Piinks · 2026-06-24T19:58:34Z

I've marked this PR as not ready to port to flutter/packages yet.
We'll provide instructions to move this change over to material_ui/cupertino_ui once ready to receive PRs. Thank you!

The changes not in the material or cupertino libraries will remain here.

Piinks · 2026-06-24T23:36:30Z

Advice for PR splitting: Since this touches material/cupertino along with other parts of flutter/flutter, it will need to be split up.

If the material/cupertino changes are dependent on the other non-material/cupertino changes in this PR, then the material/cupertino changes will need to wait for them to roll to stable before they can be ported over to material_ui/cupertino_ui in flutter/packages (which uses the stable branch).

If that is the case here, consider opening a new PR with the non-material/cupertino changes to move forward with so that waiting period can be reduced. Up to you!

reidbaker · 2026-07-23T15:47:46Z

@justinmc what is the status of this pr do you want review?

Piinks · 2026-08-18T20:19:01Z

When ready, material_ui and cupertino_ui are now accepting contributions. The portions of this PR that affect the material and cupertino libraries can be ported over to flutter/packages. Guidance and instructions for easily porting over can be found in #188444

justinmc · 2026-08-18T20:32:44Z

I'll close this since it does have a few places where it touches Cupertino.

justinmc added 2 commits July 24, 2024 15:54

WIP exploring if I can automatically add a PopScope to nested Navigat…

b011ed3

…or widgets

Automatically catch back gestures in nested Navigators

b6af916

justinmc self-assigned this Jul 25, 2024

justinmc marked this pull request as draft July 25, 2024 17:41

github-actions Bot added framework flutter/packages/flutter repository. See also f: labels. f: routes Navigator, Router, and related APIs. labels Jul 25, 2024

Clean up

09c5b70

justinmc force-pushed the automatic-pop-scope branch from ae6a6e8 to 09c5b70 Compare July 25, 2024 17:55

Fix CupertinoTabScaffold, which deactivates Navigator when its tab is…

1263a99

… active The tabs are not managed by routes, they are just shown and hidden, so this widget needs special custom handling of backs. This is a good example of when we can't do this automatically.

github-actions Bot added the p: cupertino_ui cupertino_ui package in flutter/packages label Jul 26, 2024

justinmc added 3 commits July 29, 2024 13:55

handle to handles

adb2308

Fix navigator tests by simplifying them.

6d3ae96

They don't need to do PopScope themselves anymore.

Investigating predictive back not working when regular route transiti…

a02642e

…ons do work Red herring, it only happens in complex interleaving scenarios, and that is a bug in master too.

github-actions Bot added the p: material_ui material_ui package in flutter/packages label Jul 30, 2024

justinmc marked this pull request as ready for review July 30, 2024 21:20

Merge branch 'master' into automatic-pop-scope

a87f23a

chunhtai self-requested a review July 30, 2024 22:30

justinmc added 2 commits July 31, 2024 09:59

Docs for handlesBacksWhenNested

bf8c276

Merge branch 'master' into automatic-pop-scope

6a75c8e

chunhtai reviewed Jul 31, 2024

View reviewed changes

Update packages/flutter/lib/src/material/predictive_back_page_transit…

9e7856d

…ions_builder.dart Co-authored-by: chunhtai <[email protected]>

justinmc marked this pull request as draft August 2, 2024 23:36

justinmc mentioned this pull request Aug 2, 2024

Predictive back can close app when navigation stack is not empty #145290

Open

Example of nested Navigator.pages working with predictive back

da4eae2

github-actions Bot added d: api docs Issues with https://api.flutter.dev/ d: examples Sample code and demos labels Aug 8, 2024

justinmc requested a review from chunhtai September 16, 2025 18:07

chunhtai reviewed Sep 23, 2025

View reviewed changes

justinmc added 3 commits September 26, 2025 13:57

Getter/property/setter

f179cf4

Future proof in case called not during build

5fdde3b

Comments on lastCanPop

92a49c9

justinmc requested a review from chunhtai September 26, 2025 21:40

chunhtai previously approved these changes Sep 29, 2025

View reviewed changes

justinmc added 2 commits September 29, 2025 15:31

Merge branch 'master' into automatic-pop-scope

f308c51

Shouldn't be needed, but is it working around a Google failure?

8b0f3a5

maRci002 mentioned this pull request Nov 7, 2025

Interleaved nested Navigators and Predictive Back #152323

Open

Merge branch 'master' into automatic-pop-scope

04fbdcf

justinmc dismissed chunhtai’s stale review via 04fbdcf March 12, 2026 22:21

maRci002 mentioned this pull request Mar 13, 2026

Nested Navigator back gestures trigger pop in all Navigator instead of the deepest Navigator #183597

Closed

This comment was marked as off-topic.

Sign in to view

dkwingsmt marked this pull request as draft March 25, 2026 18:19

Piinks added the Decoupling: Not ready to port yet Instructions will be provided when this is ready to move to flutter/packages. label Jun 24, 2026

Piinks added the Decoupling: Split PR The PR will need to be split to separate Material & Cupertino changes label Jun 24, 2026

Piinks added Decoupling: Port to flutter/packages This PR is ready to be ported to flutter/packages. We will provide instructions to do so. and removed Decoupling: Not ready to port yet Instructions will be provided when this is ready to move to flutter/packages. labels Aug 18, 2026

justinmc closed this Aug 18, 2026

veto9292 mentioned this pull request Sep 21, 2026

[go_router] Back button stops working app-wide after leaving a StatefulShellRoute branch that has sub-routes #193098

Open

Conversation

justinmc commented Jul 25, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Multiple nested Navigators

TODO

Uh oh!

flutter-dashboard Bot commented Jul 25, 2024

Uh oh!

justinmc commented Jul 31, 2024

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

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!

maRci002 commented Aug 1, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

justinmc commented Aug 2, 2024

Uh oh!

justinmc commented Sep 16, 2025

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!

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!

chunhtai left a comment

Choose a reason for hiding this comment

Uh oh!

chunhtai Sep 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

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!

Piinks commented Dec 8, 2025

Uh oh!

This comment was marked as off-topic.

flutter-dashboard Bot commented Mar 25, 2026

Uh oh!

Piinks commented Jun 24, 2026

Uh oh!

Piinks commented Jun 24, 2026

Uh oh!

reidbaker commented Jul 23, 2026

Uh oh!

Piinks commented Aug 18, 2026

Uh oh!

justinmc commented Aug 18, 2026

Uh oh!

Reviewers

Assignees

justinmc commented Jul 25, 2024 •

edited

Loading

maRci002 commented Aug 1, 2024 •

edited

Loading

chunhtai Sep 29, 2025 •

edited

Loading