Pop scope
- Yes, and no. It’s important to understand the sequence of events.
- PopScope does not stop the navigation attempt before the callback runs.
- It registers intent, controls whether the underlying route manager allows the pop,
and then the callback (
onPopInvokedWithResult) fires after that decision has been made.
canPop: true (Default) | canPop: false (Block Navigation) | |
| 1. User Action | System back gesture or Navigator.pop() is called. | System back gesture or Navigator.pop() is called. |
| 2. Route Decision | The route layer allows the pop to proceed. | The route layer blocks the pop. |
| 3. Callback Fires | onPopInvokedWithResult is called with didPop: true. | onPopInvokedWithResult is called with didPop: false. |
| 4. Result | The screen disappears immediately. | The screen stays put. (You must manually call Navigator.pop() later if you want to dismiss it after a confirmation dialog). |
- User clicks your “
Close Modal” TextButton. - The
TextButtoncallsNavigator.of(context).pop(). This initiates a pop attempt. - The
PopScopeseescanPop: false, so the underlyingNavigatorignores the pop attempt initiated by the button. - The
onPopInvokedWithResultis fired withdidPop: false. - Inside your
onPopInvokedWithResultcallback, you likely have code that callsNavigator.of(context).pop()again, probably inside a confirmation dialog (as shown in my previous example). - This sequence might cause unexpected behavior if your manual button pop and the PopScope logic collide awkwardly in the modal’s lifecycle, potentially processing two separate requests across different navigators if one of your contexts was subtly wrong.