[CollapsingToolbarLayout] CollapsingToolbarLayout performs unwanted toolbar stretching

[pubiqq]

https://user-images.githubusercontent.com/82187521/166513764-388f2ea8-d42e-4545-ac33-ee990e6a1d98.mp4

Material Library version: 1.7.0-alpha01

[drchen]

Hi, is it from our Collapsing Demo (Medium)?

I can't really reproduce it. Are you modifying anything with the catalog settings? What device are you using?

[pubiqq]

• Yes, it's from M3 Catalog, without any changes (checked on the 1.6.0 tag and the current master branch).
• Video was captured on Pixel 4a 5G (Android 12), but this issue is reproduced on other devices as well.

I recorded another video, but with enabled "Pointer location". If it doesn't help you, let me know, and I'll find another way to show this issue.

https://user-images.githubusercontent.com/82187521/166834467-4aefd4a0-9dcf-4581-930b-05f1dd7d61af.mp4

[drchen]

Hi, thanks for the info. In the second recording you provide, I don't see the same issue as in the first recording.

Would you mind to elaborate more about the issue you saw?

[pubiqq]

I'm talking about an effect that looks like the appbar starts to expand when scrolling up, but then immediately changes its mind, and the expanded piece fades out.

To make this effect more noticeable, try to set the following resource values:

• design_appbar_elevation - 64dp
• app_bar_elevation_anim_duration - 1500

https://user-images.githubusercontent.com/82187521/166883414-b1fe0bd4-a75d-4cb3-b606-3679a0e042c1.mp4

[drchen]

Ah I got it. Unfortunately I don't really feel it's something we are able to fix though.... It looks like something caused by the way how the framework handles View.offsetTopAndBottom(). It moves the view to its new location even without calling draw() and we have no chance to intervene before that happens and adjust the layout.

We will do more investigation on it but we probably won't have a quick fix on this. (And I'm not sure if we will make a complete refactor of how top app bar works to solve this.) Stay in tune.

[pubiqq]

Let me save you some time, the cause is much simpler - CollapsingToolbarLayout scrim covers the AppBarLayout elevation animation. You can comment out the line:

animateScrim(shown ? 0xFF : 0x0);

in CollapsingToolbarLayout.java and the problem will disappear.

Or, you can set:

android:stateListAnimator="@null"

to com.google.android.material.appbar.AppBarLayout and it will work too (but the app bar will have a slightly different behavior).

[drchen]

Hi, thanks for the info. It's indeed an issue that the liftOnScroll behavior and the scrim animation interfere each other. But it's something configurable (like, you can just disable liftOnScroll).

The issue is that I think the expected behavior of the scrim is "staying in the same position rather than stretching while scrolling". However under the current implementation it seems quite hard to fix the race condition between scrolling and scrim position adjusting...

If you just want a smooth UX, setting content scrim to null seems a reasonable solution?

[pubiqq]

But it's something configurable (like, you can just disable liftOnScroll).

app:liftOnScroll="false" has no effect (checked on the current master branch)

The issue is that I think the expected behavior of the scrim is "staying in the same position rather than stretching while scrolling".

I think it should be clarified with the designer. Even so, okay, it can be achieved with android:stateListAnimator="@null", but I would prefer the library to take care of it.

However under the current implementation it seems quite hard to fix the race condition between scrolling and scrim position adjusting...

I'm not sure what race you're talking about. I just think CollapsingToolbarLayout shouldn't fade in chunks like here (screenshots are captured from the video):

[drchen]

Yeah I agree. I guess we are talking about different things.

I think the issue you demonstrated in the screenshots is caused by having liftOnScroll="true" and contentScrim at the same time. (Not sure why app:liftOnScroll="false" has not effect in your case but it actually controls the state-list animator.) I totally agree it's a nasty behavior but I'm not sure which setting should take the priority here - liftOnScroll or contentScrim? Maybe we should deprecate one of them but we need to, as you said, clarify the behavior with our designers first.

The issue I was talking about is the jankiness when you scroll down from the collapsed state - you will see the content scrim being moved down for a little bit before it jumps back to the original position. This is quite hard to solve as long as I felt from some quick investigations.

[pubiqq]

Not sure why app:liftOnScroll="false" has not effect in your case but it actually controls the state-list animator

Even with app:liftOnScroll="false", the AppBarLayout considers itself liftable, because there is CollapsingToolbarLayout with collapsible flags inside AppBarLayout.

The issue I was talking about is the jankiness when you scroll down from the collapsed state - you will see the content scrim being moved down for a little bit before it jumps back to the original position. This is quite hard to solve as long as I felt from some quick investigations.

Still unclear what you're talking about, but just in case, I'll clarify that all the movements on the screen were done without taking my finger off (you can tell by the pointer location).

[drchen]

About app:liftOnScroll="false" - yeah you are right. I didn't see we force liftOnScroll to be true when the child is collapsible.

The case I'm talking about happens only at the very first moment when you start scrolling. But given that it's not something you are concerned with, let's not bother it for now.