-
Notifications
You must be signed in to change notification settings - Fork 26.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enable gesture immediately on the underlying page when swiping back #140704
base: master
Are you sure you want to change the base?
Conversation
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
Hi @toda-bps. Thank you for taking the time to put this PR together. Looks like there's some test failures in |
In my local environment, the tests Where can I find detailed logs of test failures? Edit: These screenshots were a mistake: I checked out the wrong commit. |
You can find logs by selecting "Details" next to a failed check -> then "View more details on flutter-dashboard" near the bottom -> then looking under Steps and Logs. Usually Edit: oh, you found it while I was typing. Oops. |
1da4ed3
to
a944492
Compare
* Introduce Navigator.popGestureStarted. * Enable gesture immediately on the underlying page when swiping back using CupertinoRouteTransitionMixin. * Add cupertino/page_transition_test.dart.
I tried to fix the test failure, but realized that it was difficult to improve the swipeback behavior while preserving the existing behavior using the previous methods. So, I implemented another method that allows Navigator to have a separate userGestureInProgress that indicates the start of the pop gesture.
This method improves swipeback behavior while allowing existing tests to pass. However, I don't think this method is optimal because it adds a public property with limited use to Navigator, and I think it might be better to stop this PR. I'd like to ask for some advice. |
@chunhtai I'm not super familiar with navigator design. Can you take a look at this concern? |
This pull request executed golden file tests, but it has not been updated in a while (20+ days). Test results from Gold expire after as many days, so this pull request will need to be updated with a fresh commit in order to get results from Gold. For more guidance, visit Writing a golden file test for Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing. |
@@ -3516,6 +3516,9 @@ class NavigatorState extends State<Navigator> with TickerProviderStateMixin, Res | |||
|
|||
bool get _usingPagesAPI => widget.pages != const <Page<dynamic>>[]; | |||
|
|||
/// Whether the route was started popping by user gesture. | |||
bool popGestureStarted = false; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a confusing name, should probably called inAutomatedPopGesture, or finalizingPopGesture
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This property contradict the userGestureInProgressNotifier
, which is unfortunate.
It looks like userGestureInProgressNotifier
needs a new name like userGestureDrivenPopInProgress
, or update its logic to match its name. The former will be a breaking change, the latter will require making cupertinoPageTransition more resilient (See
// Keep the userGestureInProgress in true state since AndroidBackGesturePageTransitionsBuilder |
@@ -957,8 +957,9 @@ class _ModalScopeState<T> extends State<_ModalScope<T>> { | |||
builder: (BuildContext context, Widget? child) { | |||
final bool ignoreEvents = _shouldIgnoreFocusRequest; | |||
focusScopeNode.canRequestFocus = !ignoreEvents; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if you want user interaction, we should probably also allow request focus
Hey @toda-bps would you like to continue working on this PR and address the above feedback? |
Fixes #48225.
The behavior fixed in this pull request will probably not be completely identical to iOS native, but it will improve the user experience over the current state.
(See also: #48225 (comment))
Pre-launch Checklist
///
).If you need help, consider asking for advice on the #hackers-new channel on Discord.