IssueTracker

Attached the sample project here.

Seems to still occur on version 26.0.0 of the support library.

I'm also encountering this issue on 26.0.0 with the same scroll flags.

Thank you for reporting this issue. We have shared this with our product and engineering team and will update this issue with more information as it becomes available.

@5 Thank you. This issue occurs on various Android versions, including emulator.

@5 Note that this occurs also with RecyclerView.

@5 Attached sample with RecyclerView.

Encountering the same issue, definitely a bug.

A possible workaround can be found here:
https://stackoverflow.com/a/45338791/878126

I've also found another issue with the support library, that causes crashes on rare cases on Android 6 (and maybe others), here:
https://issuetracker.google.com/issues/64431012

I can confirm the bug occurs when 'snap' is added to the scroll flags, but is fine otherwise. The bouncing behavior occurs with a short flick gesture that does not move the scroll position past the crossover point. If it falls short of the crossover point, it bounces back to the start position before partially changing the toolbar scroll.

And it is still not fixed in support library 26.0.1 and 26.0.2 =(

Can confirm this issue on versions from 26.0.0 to 26.0.2. With previous versions everything works fine.
Tested on devices with Android from 5 to 7.

Define property in XML as follows:

app:layout_scrollFlags="scroll|exitUntilCollapsed|snap"

Got the same issue using 26.0.0, 26.0.1 and 26.0.2.
However it works fine in 25.4.0.

Tested on Nexus 6P API 23.

I need 26.0.x support library version for the new tooltips. However I can't because it breaks every collapsing toolbar in my app.

Same issue, bouncing effect + fling broken with 26.0.0, 26.0.1 and 26.0.2, no problem with 25.4.0

Thank you

Also having same issue as described above!

Thanks in advance

Same issue with 26.+ and still not fixed in 27.0.0.

Can confirm. This is still happening for us in 27.0.0. Would be so great to have a fix here. This prevents us from updating - we have to use version 26.0.0-beta1.

Yeah, I was on 26.0.2, faced this problem, then updated to 27.0.0, the issue still persists!

Same issue with me. Is there any progress?

Same issue here, any news?

I and a lot of my friends get this problem. It occurs from version 26+

Same issue, any news ?

same 27.0.2

I'm experiencing the same issue on 27.1.0.

I can confirm this on 27.1.0.
However, the bug is slightly noticeable on my Nexus 5X and a lot more accentuate on other devices like Huawai's.

not fixed yet

the same problem 27.1.0

same problem on 27.1.1   :\

For everyone still stuck with this issue, I've tried a very simple workaround which I found somewhere on stackoverflow (can't find the source atm)

The problems seem to occur because of the onStartNestedScroll() and onStopNestedScroll(() being called out of place in quick succession of each other.
Simply overriding these methods by extending an AppBarLayoutBehavior and having a lock on these methods has beautifully solved these issues for us in our production release.
Then, just add this custom behavior to your AppBarLayouts xml.
For reference:

public class SnappyAppBarLayoutBehavior extends AppBarLayout.Behavior {

    private boolean skipNextStop;
    private boolean nestedScrollStopping;

    public SnappyAppBarLayoutBehavior() {
        super();
    }

    public SnappyAppBarLayoutBehavior(Context context, AttributeSet attrs) {
        super(context, attrs);
    }

    @Override
    public boolean onStartNestedScroll(CoordinatorLayout parent, AppBarLayout child, View directTargetChild, View target, int nestedScrollAxes, int type) {
        if (!nestedScrollStopping) {
            onStopNestedScroll(parent, child, target, type);
            skipNextStop = true;
        }
        nestedScrollStopping = false;
        return super.onStartNestedScroll(parent, child, directTargetChild, target, nestedScrollAxes, type);
    }

    @Override
    public void onStopNestedScroll(CoordinatorLayout coordinatorLayout, AppBarLayout abl, View target, int type) {
        if (skipNextStop) {
            skipNextStop = false;
            return;
        }
        if (nestedScrollStopping) {
            return;
        }
        nestedScrollStopping = true;
        //The type is always set to TYPE_TOUCH to enable snapping while flinging aswell
        super.onStopNestedScroll(coordinatorLayout, abl, target, ViewCompat.TYPE_TOUCH);
    }
}

@30 Does it fix all of the issues I've written about ? Even the glitches (artifacts)  ?

@31 Yes, we've been using it in production for a few weeks now and haven't observed those glitches.

@32 Seems like it's mentioned in the post I've written about:
https://stackoverflow.com/a/48866054/878126
And that I even answered that it works well, except for the part that it has artifacts.
I've tested it again, and it still has artifacts. Tested even with latest version of everything.

I'm an author of this workaround. I suppose "artifacts" are somehow connected with using CollapsingToolbarLayout. Just don't want to investigate any further because I use plain AppBarLayout and don't observe the "artifacts".

Disagreed. You don't observe the "artifacts" because you do not reproducing properly. Or you're avoiding with purposes.

The #30 fix does worked, thanks. But I bit awkward, It is only snap when the fling is completely stop, this is differ than Api25.

Nested scrolling was rewritten completely in support library 26 (CoordinatorLayout and AppBarLayout rely on it massively). So there is no surprise that behavior changed in version 26. It is unlikely that fix #30 causes this behavior.

I dont understand why Google kept secret about this bug and put all of this issue at P4. AT LEASE you should given explain why "snap" become a limitation on new API, and given a ALTERNATE SOLUTION. Developers wants a trusted API

This is fixed in the AndroidX artifact!!!!!! Tested with beta 1.

Snapping works properly in 28.0.0-beta01. But, this is still an issue:

"2. Sometimes it shows dark color at the top, as if the status bar got expanded too (artifacts)"

When the toolbar is collapsed and you fling to expand it, the statusbar scrolls down on top of the the content of the CollapsingTL.
It can be easily reproduced with a very tall AppBarLayout (e.g. 500dp) so there's enough space to fling.
Also, it's easier to see with a dark-themed toolbar over a light content.

Not working on 28.0.0-beta01.
The real fix is to use custom AppBarLayout.Behavior

public class FixedAppBarLayoutBehavior extends AppBarLayout.Behavior {

    private int mStartedScrollType = -1;
    private boolean mSkipNextStop;

    public FixedAppBarLayoutBehavior() {
        super();
    }

    public FixedAppBarLayoutBehavior(Context context, AttributeSet attrs) {
        super(context, attrs);
    }

    @Override
    public boolean onStartNestedScroll(CoordinatorLayout parent, AppBarLayout child, View directTargetChild, View target, int nestedScrollAxes, int type) {
        if (mStartedScrollType != -1) {
            onStopNestedScroll(parent, child, target, mStartedScrollType);
            mSkipNextStop = true;
        }
        mStartedScrollType = type;
        return super.onStartNestedScroll(parent, child, directTargetChild, target, nestedScrollAxes, type);
    }

    @Override
    public void onStopNestedScroll(CoordinatorLayout coordinatorLayout, AppBarLayout abl, View target, int type) {
        if (mSkipNextStop) {
            mSkipNextStop = false;
            return;
        }
        if (mStartedScrollType == -1) {
            return;
        }
        mStartedScrollType = -1;
        // Always pass TYPE_TOUCH, because want to snap even after fling
        super.onStopNestedScroll(coordinatorLayout, abl, target, ViewCompat.TYPE_TOUCH);
    }
}

We will be closing this bug as Obsolete. If you still think this issue is reproducible and relevant in the latest Android release (Android Q), please attach a new bug report along with reproduction details. If a reply is not received within the next 14 days, this issue will be closed. Thank you for your understanding.

@42 Issue still exists. Why close it?
Here, attached new project.

Request the team to take a look at comment#43.

More details are shared in the drive link here : https://drive.google.com/open?id=1OpUrYvNSU0JixsrS1S1xYq_u1l-VqEn4 (Internal only).
Request the team to take a look at the issue.

@45 Why the need for more details? It's all here...

This should go to the MDC team.

@47 MDC?
Material... Design....... Coalition?

@48 Material Design Components

@49 Oh right, this makes more sense...
:)

@46, As you said, no more details are needed here, we have been tracking it internally in Material Design Components only.
Thanks.

@51 OK then. Here:
https://www.youtube.com/watch?v=AubJS7oWaWo

still have this issue, and non of the solution works ATM, not even the custom behavior ones (the straight-up crash giving classnotfoundexception).