You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
SliverFillRemaining does not fill overscroll even with fillOverscroll option #44353
It looks like in the gist you have provided, the white Container that is a child of SliverFillRemaining has no size on its own, and in the gif, the extent to which you have scrolled in your list is beyond the size of the screen. In this case SliverFillRemaining has no 'remaining' space to fill, so it defaults to the child's size, which in this case is nothing. I think this is why there is nothing showing up at the end of your list. I also think this is the expected behavior as laid out in the API documentation for SliverFillRemaining.
You mentioned it working in a previous version of Flutter, would that previous version have included fillOverscroll? Or did that previous version not have the fillOverscroll option? I noticed in your gist you have a CustomSliverFillRemaining that uses an older implementation which does not have the fillOverscroll option. This will help identify the earlier version you referenced.
Great! Thanks for that.
It looks likes that is correct. The fillOverscroll property was introduced in #35810 and was first tagged in v1.8.3.
The previous implementation of SliverFillRemaining had a bug where it provided enough space to fill the entire screen - rather than the 'remaining' space. Is this the behavior you are expecting?
The intent is to have a background overscroll different from overall background.
For example If we have transparency effect in the header part, but we want to keep the color of overscroll to color of the content, this is useful. But right now there is no way to do that through standard components
You are right! It is very specific. The concept of filling the 'remaining' space in a scroll view is tricky. Scroll views can scroll on infinitely, so setting rules for defining 'remaining' space are strict.
In the examples you mentioned from the API docs, while the container may not have an explicitly set size, its child does (like an Icon or a Button). This is the size that informs the enclosing sliver.
I like your idea of being able to use this sliver for just customizing the overscroll area separate from the background, without an actual child to draw otherwise in the scroll view. I'll see if this is something I can adjust to make possible. :)
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 -v and a minimal reproduction of the issue.
Activity
goderbauer commentedon Nov 14, 2019
/cc @Piinks
Piinks commentedon Nov 15, 2019
Hi @radroot1, thanks for filing this issue.
It looks like in the gist you have provided, the white
Containerthat is a child ofSliverFillRemaininghas no size on its own, and in the gif, the extent to which you have scrolled in your list is beyond the size of the screen. In this caseSliverFillRemaininghas no 'remaining' space to fill, so it defaults to the child's size, which in this case is nothing. I think this is why there is nothing showing up at the end of your list. I also think this is the expected behavior as laid out in the API documentation for SliverFillRemaining.You mentioned it working in a previous version of Flutter, would that previous version have included
fillOverscroll? Or did that previous version not have thefillOverscrolloption? I noticed in your gist you have aCustomSliverFillRemainingthat uses an older implementation which does not have thefillOverscrolloption. This will help identify the earlier version you referenced.radroot1 commentedon Nov 15, 2019
Hello.
Yes, it did not had that option. Hmm, I just found old log file, I believe it was 1.7.8+hotfix.4
Piinks commentedon Nov 15, 2019
Great! Thanks for that.
It looks likes that is correct. The
fillOverscrollproperty was introduced in #35810 and was first tagged in v1.8.3.The previous implementation of
SliverFillRemaininghad a bug where it provided enough space to fill the entire screen - rather than the 'remaining' space. Is this the behavior you are expecting?radroot1 commentedon Nov 15, 2019
Hmm, I am looking the way to fill overscroll not exactly the sceen, but it seems that this bug is what I need :)
Piinks commentedon Nov 15, 2019
Ok! Can you describe the behavior you would like to see?
radroot1 commentedon Nov 15, 2019
The intent is to have a background overscroll different from overall background.
For example If we have transparency effect in the header part, but we want to keep the color of overscroll to color of the content, this is useful. But right now there is no way to do that through standard components
radroot1 commentedon Nov 15, 2019
Hm, fillOverscroll seems to be working when I have child container with Align and not zero height like in example, this is weirdly specific
Piinks commentedon Nov 18, 2019
You are right! It is very specific. The concept of filling the 'remaining' space in a scroll view is tricky. Scroll views can scroll on infinitely, so setting rules for defining 'remaining' space are strict.
In the examples you mentioned from the API docs, while the container may not have an explicitly set size, its child does (like an Icon or a Button). This is the size that informs the enclosing sliver.
I like your idea of being able to use this sliver for just customizing the overscroll area separate from the background, without an actual child to draw otherwise in the scroll view. I'll see if this is something I can adjust to make possible. :)
radroot1 commentedon Nov 19, 2019
OK, thanks :)
Piinks commentedon Dec 4, 2019
#45121 has been closed in favor of refactoring this widget for better read/review-ability.
I don't anticipate that delaying this fix for too long, but will keep this updated as the fix gets closer to landing. :)
github-actions commentedon Aug 23, 2021
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.