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

Improve the behavior of Scrollable.ensureVisible when Scrollable nested #65226

Merged
merged 7 commits into from Sep 28, 2020

Conversation

xu-baolin
Copy link
Member

@xu-baolin xu-baolin commented Sep 4, 2020

Description

If there are multiple scrollable widgets nested, we should let the inner targetRenderObject as visible as possible to improve the user experience. Otherwise, let the outer renderObject as visible as possible maybe cause the targetRenderObject invisible.

Related Issues

Fixes #65100

Tests

I added the following tests:

See files.

@flutter-dashboard flutter-dashboard bot added the framework flutter/packages/flutter repository. See also f: labels. label Sep 4, 2020
@xu-baolin
Copy link
Member Author

@Hixie Please review :)

Comment on lines +628 to +633
/// The optional `targetRenderObject` parameter is used to determine which area
/// of that object should be as visible as possible. If `targetRenderObject` is null,
/// the entire [RenderObject] (as defined by its [RenderObject.paintBounds])
/// will be as visible as possible. If `targetRenderObject` is provided it should be
/// a descendant of the object.
///
Copy link
Contributor

Choose a reason for hiding this comment

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

Why wouldn't you just specify the targetRenderObject as the object parameter?

Copy link
Member Author

@xu-baolin xu-baolin Sep 9, 2020

Choose a reason for hiding this comment

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

@dnfield Hi,
If we only pass in the inner target RO, the outer viewport cannot be obtained by RenderAbstractViewport.of(object) at line 648 below, and we cannot get the offset to reveal the target for the outer viewport.

Copy link
Contributor

Choose a reason for hiding this comment

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

Why can't we just traverse up the viewports and get the offset for all of them?

Copy link
Member Author

@xu-baolin xu-baolin Sep 12, 2020

Choose a reason for hiding this comment

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

@dnfield
Yes, we traverse up viewport by the superior calling,

while (scrollable != null) {
futures.add(scrollable.position.ensureVisible(
context.findRenderObject(),
alignment: alignment,
duration: duration,
curve: curve,
alignmentPolicy: alignmentPolicy,
targetRenderObject: targetRenderObject,
));

Here just a correction to the area to be displayed.

Copy link
Contributor

Choose a reason for hiding this comment

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

Ohhhh I see now, we're using this parameter to memoize which object we were initially trying to center and let the viewports know that's the one - we don't expect callers to actually pass this in as a duplicate of object. Is that correct?

Copy link
Member Author

Choose a reason for hiding this comment

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

@dnfield
You are absolutely correct.
Actually, if the caller does this, it has the same effect as setting it to null, which means the target area is itself.

@dnfield
Copy link
Contributor

dnfield commented Sep 14, 2020

Can you merge this branch up to HEAD and push a new commit? I think the CI should be a flake that was resolved in master.

@xu-baolin
Copy link
Member Author

Can you merge this branch up to HEAD and push a new commit? I think the CI should be a flake that was resolved in master.

Done.

@dnfield
Copy link
Contributor

dnfield commented Sep 15, 2020

You now have some merge conflicts - can you merge again?

@xu-baolin
Copy link
Member Author

You now have some merge conflicts - can you merge again?

Done : )

Copy link
Contributor

@dnfield dnfield left a comment

Choose a reason for hiding this comment

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

LGTM

@fluttergithubbot
Copy link
Contributor

This pull request is not suitable for automatic merging in its current state.

  • The status or check suite Google testing has failed. Please fix the issues identified (or deflake) before re-applying this label.

@xu-baolin
Copy link
Member Author

xu-baolin commented Sep 16, 2020

@dnfield I'm sorry I broke the internal test case, please help me investigate at your convenient, thank you very much.
If possible, you can also give me the test case, I will investigate the reason.

@dnfield
Copy link
Contributor

dnfield commented Sep 18, 2020

My understanding is that this won't have to change to get landed, but it may take a few more days before everything is resolved internally and I don't want to add to confusion.

@Piinks Piinks added the f: scrolling Viewports, list views, slivers, etc. label Sep 22, 2020
@Piinks
Copy link
Contributor

Piinks commented Sep 22, 2020

It looks like this is blocked by the NNDB migration.

@xu-baolin
Copy link
Member Author

It looks like this is blocked by the NNDB migration.

So how can I fix it or just wait for googler to fix it?
Thanks.

@dnfield
Copy link
Contributor

dnfield commented Sep 28, 2020

I'm pretty sure this is ok now. Going to land it. Will revert if necessary.

@dnfield dnfield merged commit 73b6398 into flutter:master Sep 28, 2020
@dnfield
Copy link
Contributor

dnfield commented Sep 29, 2020

This is breaking a google3 test. I'll work on getting a reproducible test case for it, but we have to rever tfor now.

dnfield added a commit that referenced this pull request Sep 29, 2020
@xu-baolin
Copy link
Member Author

This is breaking a google3 test. I'll work on getting a reproducible test case for it, but we have to rever tfor now.

I am sorry for breaking something.
Please let me known if you reproduce an external test case and I will investigate it.
Thanks :)

dnfield added a commit to dnfield/flutter that referenced this pull request Oct 9, 2020
dnfield added a commit that referenced this pull request Oct 10, 2020
* Revert "Revert "Improve the behavior of Scrollable.ensureVisible when Scrollable nested (#65226)" (#66918)"

This reverts commit e8812c4.

* Fix for page views

* comment
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.

Scrollable.ensureVisible does not work with nested SingleChildScrollViews on both axes
5 participants