Skip to content
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

DraggableScrollableSheet & NestedScrollView should respect NeverScrollableScrollPhysics #123109

Merged
merged 2 commits into from Apr 12, 2023

Conversation

xu-baolin
Copy link
Member

@xu-baolin xu-baolin commented Mar 21, 2023

Fixes #121021
Fixes #113753

#121021 was introduce by #109081

Adding a ScrollPhysics.allowUserScrolling to indicate whether the physics allowed the user scrolling.

@flutter-dashboard flutter-dashboard bot added f: scrolling Viewports, list views, slivers, etc. framework flutter/packages/flutter repository. See also f: labels. labels Mar 21, 2023
@xu-baolin xu-baolin requested a review from Piinks March 21, 2023 13:00
@@ -969,4 +972,7 @@ class NeverScrollableScrollPhysics extends ScrollPhysics {

@override
bool get allowImplicitScrolling => false;

@override
bool get allowUserScrolling => false;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Doesn't shouldAcceptUserOffset above provide the same thing?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, the default implementation of shouldAcceptUserOffset might not work as this is intended. However, I think if adding this allowUserScrolling is the right way to resolve this, it should work with shouldAcceptUserOffset, or at least document what the difference between them is. Should shouldAcceptUserOffset also consider allowUserScrolling?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Piinks Nice point! Let us review the original issue again : )
1, The framework warp a gesture recognizer only if physics.shouldAcceptUserOffset(this) returns true.

void setCanDrag(bool value) {
if (value == _lastCanDrag && (!value || widget.axis == _lastAxisDirection)) {
return;
}
if (!value) {

So, If the DSS's extent becomes large enough, the scrollable will become unscrollable and the gesture will be removed (The extent's size is actually the scrollable viewport). Then the DSS is stuck and cannot be pulled back. This is the #31739 root cause.

2, Here is _DraggableScrollableSheetScrollPosition.applyUserOffset 's implement

void applyUserOffset(double delta) {
if (!listShouldScroll &&
(!(extent.isAtMin || extent.isAtMax) ||
(extent.isAtMin && delta < 0) ||
(extent.isAtMax && delta > 0))) {
extent.addPixelDelta(-delta, context.notificationContext!);

It set the extent's size by the user scrolling. So, if we want fix the original issue we must let the scrollable always scrollable, right?

Regardless of whether #31832 or #109081, they essentially make the scrollable to be always scrollable, but #31832 is a bit hack and introduces issue #98314.

Unfortunately, #109081 introduces issue #121021 because it ignores the ‘NeverScrollableScrollPhysics’ case. This is why I make this change to introduce a method to distinguish the NeverScrollableScrollPhysics and others.

In addition, I tried other solutions at the same time, such as caching the old physics, and then applying it to the user scrolling, but I gave up for it is a bit complicated.

Glad to here your thoughts : )

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah thank you for this! I really appreciate the context. I came across #113753 which is a similar-ish case of the explicit physics being overridden by a widget applying other physics.

This makes me think, what do you think about some way for users to specify that physics should not be meddled with? And then maybe in applyTo we check that? I dunno, just brainstorming..
However, this is slightly different from #113753 in that in the nested scroll view, we see userSuppliedPhysics.applyTo(extraImplementationPhysics), while here we see extraImplementationPhysics.applyTo(userSuppliedPhysics).. so this idea may not actually work...

Since it appears there is a pattern where the user may not want us to to change the scroll physics (I am sure there are other places where we do this, overriding the value explicitly set by the user), what are you thoughts on approaching this in a way that lets users preserve their preferred scroll physics? (not exclusive to just NeverScrollable and allowUserScrolling)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah thank you for this! I really appreciate the context. I came across https://github.com/flutter/flutter/issues/113753 which is a similar-ish case of the explicit physics being overridden by a widget applying other physics.

It seems like physics overridden is not the root cause of that issue but this patch may help to fix that : )

This makes me think, what do you think about some way for users to specify that physics should not be meddled with?

Good idea but I'm concerned that doing this would be a breaking change?

@xu-baolin xu-baolin force-pushed the xbl230320 branch 2 times, most recently from 56c008d to d33b342 Compare March 23, 2023 02:54
@xu-baolin xu-baolin requested a review from Piinks March 23, 2023 12:42
Copy link
Contributor

@Piinks Piinks left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know that this is the right approach, I actually wonder if the original fix for #98314 was not the right solution. Applying AlwaysScrollableScrollPhysics may have other side effects like we are seeing here with NeverScrollableScrollPhysics.
I am not sure what the right change is, but I'd like to see if we can revisit the original issue and check to see if there is a better solution there first. What do you think @xu-baolin?

@xu-baolin xu-baolin force-pushed the xbl230320 branch 2 times, most recently from 9e448a8 to 8fd6b36 Compare April 10, 2023 03:13
@xu-baolin xu-baolin changed the title DraggableScrollableSheet should respect NeverScrollableScrollPhysics DraggableScrollableSheet & NestedScrollView should respect NeverScrollableScrollPhysics Apr 10, 2023
@@ -781,7 +781,7 @@ class _DraggableScrollableSheetScrollController extends ScrollController {
ScrollPosition? oldPosition,
) {
return _DraggableScrollableSheetScrollPosition(
physics: const AlwaysScrollableScrollPhysics().applyTo(physics),
physics: physics.applyTo(const AlwaysScrollableScrollPhysics()),
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

userSuppliedPhysics.applyTo(extraImplementationPhysics) can fix DDS's issue simply : )

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Excellent!

@@ -1439,7 +1439,8 @@ class _NestedScrollPosition extends ScrollPosition implements ScrollActivityDele
}

void updateCanDrag(double totalExtent) {
context.setCanDrag(totalExtent > (viewportDimension - maxScrollExtent) || minScrollExtent != maxScrollExtent);
context.setCanDrag(physics.allowUserScrolling &&
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixes #113753

Here seems to be more suitable use physics.allowUserScrolling

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah yes, thank you!

Copy link
Contributor

@Piinks Piinks left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for your patience on this one. I really appreciate you taking a look at that other issue and including a full fix! LGTM!

@Piinks Piinks added the autosubmit Merge PR when tree becomes green via auto submit App label Apr 11, 2023
@auto-submit auto-submit bot removed the autosubmit Merge PR when tree becomes green via auto submit App label Apr 11, 2023
@auto-submit
Copy link
Contributor

auto-submit bot commented Apr 11, 2023

auto label is removed for flutter/flutter, pr: 123109, due to - The status or check suite Mac customer_testing has failed. Please fix the issues identified (or deflake) before re-applying this label.

@Piinks Piinks added the autosubmit Merge PR when tree becomes green via auto submit App label Apr 11, 2023
@auto-submit auto-submit bot merged commit 328635b into flutter:master Apr 12, 2023
72 checks passed
@aqrc
Copy link

aqrc commented Apr 12, 2023

Thank you very much for fixing that! Could you please estimate when this fix is going to be officially released?

engine-flutter-autoroll added a commit to engine-flutter-autoroll/packages that referenced this pull request Apr 12, 2023
exaby73 pushed a commit to NevercodeHQ/flutter that referenced this pull request Apr 17, 2023
…lableScrollPhysics (flutter#123109)

DraggableScrollableSheet & NestedScrollView  should respect NeverScrollableScrollPhysics
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
autosubmit Merge PR when tree becomes green via auto submit App f: scrolling Viewports, list views, slivers, etc. framework flutter/packages/flutter repository. See also f: labels.
Projects
None yet
3 participants