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

Wrong sticky header on first display of scrolled list #181

Closed
deakjahn opened this issue May 5, 2023 · 3 comments · Fixed by #198
Closed

Wrong sticky header on first display of scrolled list #181

deakjahn opened this issue May 5, 2023 · 3 comments · Fixed by #198
Assignees
Labels
bug Something isn't working

Comments

@deakjahn
Copy link

deakjahn commented May 5, 2023

Describe the bug
When using a grouped list inside a Scrollbar and passing it a scroll controller, depending on the scroll position, it might display with some item in the middle rather than the very first item. In this situation the top sticky header isn't correct, it shows the first item's group even if we're somewhere in the middle of the list. Only the first slight movement of the list fixes it.

Expected behavior
Correct sticky header upon initial display.

Information:

  • Dart version: 2.19.6
  • Flutter version: 3.7.12
  • Platform: Android
  • Package version: 5.1.2
@deakjahn deakjahn added the bug Something isn't working label May 5, 2023
@deakjahn
Copy link
Author

deakjahn commented May 5, 2023

The direct cause seems to be that the StreamBuilder inside _GroupedListViewState.build() only gets fired when _scrollListener explicitely calls it (list actually scrolled and the actual item changes). I can fake the initial display if I initialize _topElementIndex to something else than zero. My immediate thought would be to actually initialize it somehow if the widget.controller is provided to the control when it's started.

I'll experiment and report back with more.

@deakjahn
Copy link
Author

deakjahn commented May 5, 2023

A quick solution. I don't PR it yet, first, it's too easy, second, I don't know whether you would think it dangerous for anything else. It looks like simply removing the condition would work:

if (widget.reverse) {
_ambiguate(WidgetsBinding.instance)!.addPostFrameCallback((_) {
_scrollListener();
});
}

Just call _scrollListener() on the next frame in any case, not just for reverse.

@Dimibe
Copy link
Owner

Dimibe commented Nov 15, 2023

Fixed with #198

@Dimibe Dimibe closed this as completed Nov 15, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants