-
Notifications
You must be signed in to change notification settings - Fork 30.1k
Description
Steps to Reproduce
Create a nested navigator. The top level navigator handles back just fine, but a WillPopScope within the inner navigator is completely ignored.
This is still the case if a WidgetsBindingObserver is used with the inner navigator.
Discussion...
I've debugged through and the reason this seems to happen is that WidgetsBinding.handlePopRoute iterates forward through the list of WidgetsBindingObservers. This means observers that are registered later are lower down the list so never get called if the first layer can perform a pop. This causes a problem - if I have a nested structure, I want the lower level to be able to decide whether or not to pop before the decision is passed up the structure. But because the top level decides first, I'm going to have to write all my own wiring to propagate the decision downwards through a lower navigator.
I think that a simple fix would be to simply reverse the iteration through the list of WidgetBindingObservers in WidgetsBinding, but I realize that change could cause problems for existing projects (although theoretically if people are following the basic 'flutter' way of doing things, they would only have the one WidgetBindingObserver from the WidgetsApp making pop decisions so maybe it wouldn't cause too many problems).
I also recognize that through what I've seen in other issues & threads, flutter doesn't really want to support nested navigators. However, I think that as adoption grows you're going to see a lot more people attempting to do it as there is nothing that prohibits it, and some of the documentaiton/code make it seem like it should work (i.e. in navigator has a 'bubble RoutePopDisposition' - on close inspection it says it bubbles to the system navigator but I initially assumed it bubbled from navigator to navigator). I personally am using nested navigators because I have an app with multiple sections, and some of the sections have navigational behaviour that are quite different than others, so it made sense to create different navigators (with extra classes for the specific behaviour). And even just for code cleanliness, it's nice to be able to split up functionality into of pages that are handled individually.
Logs
N/A
Flutter Doctor
N/A really - this is with the most recent flutter & dart but is reproducible with older versions as well as the relevant code hasn't changed.
• Flutter at C:\VirtualDrives\Programs\flutter
• Framework revision 8cf109d20f (15 hours ago), 2018-01-11 23:21:53 -0800
• Engine revision 05fe72d068
• Tools Dart version 2.0.0-dev.16.0
• Engine Dart version 2.0.0-edge.28757928b47b192efcec082c78258102beb03f78