Repository navigation
How should Cupertino back gesture interact with onPopPage #137458
Description
Is there an existing issue for this?
- I have searched the existing issues
- I have read the guide to filing a bug
Steps to reproduce
Currently the Cupertino back gesture assumes its pop will always remove the route, however it missed the case where onPopPage can still veto the pop. Right now, this will cause the page to hang.
The question is what should they do in this case. I can think several ways forward.
- onPopPage can veto the pop, then we have to fix the cupertino back swipe to not freeze the screen if it is veto'd
- page based route will disable cupertino back swipe.
- cupertino backswipe can't be veto by onPopPage.
It seems to me (2) or (3) is closer to the current cupertino back swipe behavior, but (2) may be too aggressive. If we want to implement (3) we will need a new API in Navigator to still give customer a chance to clean up their page list.
Actual results
fix the issue.
Logs
Logs
<!-- Paste your logs here -->
Flutter Doctor output
Doctor output
<!-- Paste your output here -->
Activity
goderbauer commentedon Oct 30, 2023
In general, I think that vetoing a route that is dismissed via a back swipe is bad UX. From a user perspective, the expectation is that a back swipe will always be successful. If for a particular route you cannot guarantee that, it probably shouldn't support the back swipe (and instead only be dismissible by clicking a button).
I agree, that disabling the swipe for all page-based routes is too aggressive, though.
It sounds like 3 may be the right option here? Do you have a proposal for what that API would look like, though?
We probably will also run into the same problem with Android's new in-app predictable back, which is pretty similar to the current back swipe in iOS.
Do we have an easy way to disable the backswipe for a particular route if one wants to do that to be able to veto its pop?
chunhtai commentedon Oct 30, 2023
Yes, I think so, but this will be the most breaking way to handle this out of the 3
One idea is to add a new onPageDidPop callback, but I am struggling to figure out a way that is less breaking. It seems to me this onDidPopPage will need to be called if onPopPage return true, but that will make the migration a bit tricky. Customer may need to move part of the onPopPage implementation to onDidPopPage; otherwise they may be cleaning up the page list twice unknowingly
Yes the PopScope is enabling the predictive back, but the onPopPage can still veto it. It does seem like the best choice will be to go with (3). it we go with (2) the page apis will have to wire special logic to disable each of force pop mechanisms.
They will have to build a WillPopScope or PopScope in the route's widget subtree. The alternative is to add more parameter to Page class like Page.popGestureEnabled, I think that can be useful in some way, but I really don't want to further complicated the pop related API....
Refactors page API (#137792)
github-actions commentedon May 27, 2024
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of
flutter doctor -vand a minimal reproduction of the issue.Refactors page API (#137792)