IssueTracker

We havent checked Honeycomb, so expect its missbehaving since the introduction in API 11

[Comment deleted]

This same issue occurs on 4.2.2.  I have replicated it as described earlier, but found its not limited to occurring just for the first element off of the screen.  It also happens for elements that are multiples of that distance(the height of the ListView), or close to it, but not consistently.

In the example I have set up, I have an adapter with 1000 items, the items at position 0-4 are entirely visible and the item at position 5 is partially visible. Element 6 is the first off of the screen, and doing a smothScrollToPositionFromTop on that element when starting at 0 will ALWAYS only scroll far enough to show that element at the bottom(as in the original bug).  However, starting from 0, it will also happen for the element at position 9, and the element at position 13, but not every time.  With the same adapter when calling smothScrollToPositionFromTop on position 9 it happened 5 out of 10 tries.

The workaround given earlier,"A workaround for now is listening for SCROLL_STATE_IDLE when starting the scroll, and smoothScrollToPositionFromTop again to the same position." won't always work either.  For some reason when using smoothScrollToPositionFromTop to scroll over long distances(using the same list from my earlier example scrolling 40+ elements) will call onScrollStateChanged with SCROLL_STATE_IDLE multiple times for 1 smoothScrollToPositionFromTop call, going to SCROLL_STATE_IDLE and then back to SCROLL_STATE_FLING before completing.  The first call to onScrollStateChanged with SCROLL_STATE_IDLE doesn't necessarily mean the scrolling has finished.

[Comment deleted]

[Comment deleted]

@Matthew

You can check whether SCROLL_STATE_IDLE means that scrolling has finished when you also check if the position that you want to scroll to is now being visible.

You might want to adopt this code (position is where you want to scroll to):

public void onScrollStateChanged(final AbsListView view, final int scrollState) {
  if (scrollState == SCROLL_STATE_IDLE) {
    int firstPos = view.getFirstVisiblePosition();
    if ((position >= ) && (position < firstPos + view.getChildCount())) {
      // Position is now visible.
      // Now use workaround to scroll again to this position. Don't forget to remove the scroll listener / set a flag if you scroll twice
    }
  }
}

A good workaround for this bug is to first call smothScrollToPositionFromTop(position) and then, when scrolling has finished, call setSelection(position). The latter call corrects the incomplete scrolling by jumping directly to the desired position. Doing so the user still has the impression that it is being animtation-scrolled to this position. Make sure to post setSelection() with a Handler.

This is marked has fixed but I'm still facing the same bug.

Does it really fixed? I'm facing this bug. Fixed by first function

I‘m facing the same bug in 6.0.

I am facing the same bug in 7.0 as well... I wonder how this bug is marked as fixed. but with the solution provided in #8 works good... but not exactly as we expect. sometimes it working, occassionaly, it fails.

I'm also experiencing this behaviour on 8.1

Im also facing this bug

The bug exists up until now.

The bug exists up until now.

the bug exists up until now

the bug exists up until now

the bug exists up until now

That makes sense actually. I think it is better to consider ListView deprecated.