Skip to content

Conversation

@nt4f04uNd
Copy link
Member

Fixes #38357
Reland #95423
Which was reverted to be treated as breaking change here #97150

Pre-launch Checklist

  • I read the Contributor Guide and followed the process outlined there for submitting PRs.
  • I read the Tree Hygiene wiki page, which explains my responsibilities.
  • I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
  • I signed the CLA.
  • I listed at least one issue that this PR fixes in the description above.
  • I updated/added relevant documentation (doc comments with ///).
  • I added new tests to check the change I am making, or this PR is test-exempt.
  • All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

@flutter-dashboard flutter-dashboard bot added f: scrolling Viewports, list views, slivers, etc. framework flutter/packages/flutter repository. See also f: labels. labels Jan 24, 2022
@nt4f04uNd
Copy link
Member Author

nt4f04uNd commented Jan 24, 2022

@Piinks is the removal of dependency on spring what broke the customer? So a description of a breaking change would be something like "PageScrollPhysics now only use ScrollPhysics.spring when going out of range (for example on iOS), while previously it could be used to change the whole animation from user swipes".

@Piinks
Copy link
Contributor

Piinks commented Jan 24, 2022

Thanks for re-opening! Maybe that was it, what I saw in the customer tests were golden file images. They were capturing pictures of the screen after swiping through pages, but instead of being on the last page as expected, they were on the first page.
The swiping in the test was engaged with a fling gesture. I saw this exact same thing happen across two different customers. WDYT? I can try to get more context if you need it.

@nt4f04uNd
Copy link
Member Author

nt4f04uNd commented Jan 24, 2022

Thanks for the details, it might be the case that this is because of the change of minFlingDistance and/or minFlingVelocity to bigger values. More context would certainly be helpful.

@Piinks
Copy link
Contributor

Piinks commented Jan 24, 2022

Customer A

Test code to swipe to next page:

await fling(customerApp, Offset(-200, 0), 200);

I do not know if it makes a difference, but the screen ratio of this test is like a phone in landscape mode, longer across than from top to bottom.


Customer B

Same issue, swipes did not end up on the expected page index. Screen size is similar to portrait oriented phone. Swipe gesture from test:

await tester.fling(
        customerWidget,
        Offset(-200, 0),
        200,
      );

I think the way to proceed here is to add a temporary opt-in flag. I cannot change the customer tests ahead of time, because the behavior would not be right without this change.

What we usually do here is

  1. we add a temporary flag,
  2. land the change,
  3. migrate the affected customers to the new behavior using the opt in flag,
  4. change the default of the opt in flag to make it an opt out flag
  5. update customer code to stop using the flag
  6. remove flag
  7. release a migration guide documenting the breaking change

I think the ScrollBehavior might be the easiest way to do it, that way I can just opt the whole customer's app in pretty easily, and update the tests, but I'd like to know what you think about all this. Let me know and we can find a way for this to move forward. :)

@goderbauer goderbauer requested a review from Piinks January 26, 2022 22:36
@nt4f04uNd
Copy link
Member Author

(I do not forget about this and my other PRs, it's just that I don't have much time for open source now, anyway I'll try my best to move this forward)

@Piinks
Copy link
Contributor

Piinks commented Feb 17, 2022

Hey @nt4f04uNd, no worries at all. I really appreciate all of your contributions, they are often non-trivial solutions and very valuable to everyone - so thanks!
If you like, I can pick this one up and work with the affected customers to re-land it. Let me know.

Either way we'll still be here ready to work together when you come back. 😉

return targetPage - page;
}

double _getTargetPixels(ScrollMetrics position, Tolerance tolerance, double velocity) {
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 I just thought whether would it make sense to make some of these methods public, so people can restore the old implementation if they want (or just change it to whatever else)?

Copy link
Contributor

Choose a reason for hiding this comment

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

I don't know if that would be super beneficial, ultimately the changes you are introducing are the way it should be, there are just a lot of tests out there that expect the old behavior.

@nt4f04uNd
Copy link
Member Author

If you like, I can pick this one up and work with the affected customers to re-land it. Let me know

Thanks, I'd appreciate if you taken this part.

@Piinks
Copy link
Contributor

Piinks commented Feb 25, 2022

If you like, I can pick this one up and work with the affected customers to re-land it. Let me know

Thanks, I'd appreciate if you taken this part.

Just confirming, I am going to close this PR and clone it to re-open another one that I can manage landing with affected customers?

@nt4f04uNd
Copy link
Member Author

Yeah, sure 🙂

@nt4f04uNd nt4f04uNd closed this Feb 27, 2022
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.

Hey @nt4f04uNd you recently reached out and asked if this was still on my radar. It is, although I have not had the cycles to work on it actively. There are some related issues that need resolution before we can re-land this, as noted in the comments of the test you wrote below.

I also think this should be only applied when the TargetPlatform is Android. The changes here are specific to Android and as you previously established (#97064), platforms like iOS have their own unique behavior. Especially since this broke customer tests, I think it would be prudent to only apply the change to the platform it is intended to reflect. Applying it to every platform would break more customers - who may be broken again later when we adjust the behavior for other platforms, creating a lot of churn for users.

// Changing velocity for time 0 may cause a sudden, unwanted damping/speedup effect
expect(bounce.createBallisticSimulation(position, 1000)!.dx(0), moreOrLessEquals(1000));
expect(clamp.createBallisticSimulation(position, 1000)!.dx(0), moreOrLessEquals(1000));
expect(page.createBallisticSimulation(position, 1000)!.dx(0), moreOrLessEquals(1000));
Copy link
Contributor

Choose a reason for hiding this comment

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

This being removed and the comments below it seem like the other issue should really be resolved first.

@Piinks
Copy link
Contributor

Piinks commented May 23, 2022

Cross-referencing #11599 to maintain link for next planning session.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

f: scrolling Viewports, list views, slivers, etc. framework flutter/packages/flutter repository. See also f: labels.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

TabView swipe animates too slow compared to Android

2 participants