Fixed
Status Update
Comments
am...@google.com <am...@google.com>
am...@google.com <am...@google.com> #2
Thank you for reporting this issue.
Please provide the below details to investigate this issue further.
1. The file dynamic_action_bar.xml has many dependencies missed out here. So please attach your sample android project which reproduces the issue, zip it and share.
2. Explain the steps to reproduce the issue with your apk. Provide all necessary information to reproduce the issue.
3. Provide clarity on the expected and observed behavior along with the necessary screenshots.
JFYI, the latest support lib released is 26.1.0. So you can check with it and share the details if issue persists.
Please provide the below details to investigate this issue further.
1. The file dynamic_action_bar.xml has many dependencies missed out here. So please attach your sample android project which reproduces the issue, zip it and share.
2. Explain the steps to reproduce the issue with your apk. Provide all necessary information to reproduce the issue.
3. Provide clarity on the expected and observed behavior along with the necessary screenshots.
JFYI, the latest support lib released is 26.1.0. So you can check with it and share the details if issue persists.
ca...@gmail.com <ca...@gmail.com> #3
I am facing the same issue with 26.1.0 as well.
ki...@gmail.com <ki...@gmail.com> #4
The attachment is the sample project.
Steps to reproduce:
1. Launch the app
2. Scroll to "Title 20"
3. Fling down to show the action bar and the recycler view will stop scrolling at the same time.
4. Click on any item.
5. The click event will not be triggered.
The attachment of the first mail is the screen recording.
You can see more details in the first mail.
As you said that "This is a special release to integrate the Support Library with Lifecycles from Architecture Components. If you are not using the Lifecycles library, you don’t need to update from 26.0.2." on the release notes, so I don' t use the 26.1.0.
Steps to reproduce:
1. Launch the app
2. Scroll to "Title 20"
3. Fling down to show the action bar and the recycler view will stop scrolling at the same time.
4. Click on any item.
5. The click event will not be triggered.
The attachment of the first mail is the screen recording.
You can see more details in the first mail.
As you said that "This is a special release to integrate the Support Library with Lifecycles from Architecture Components. If you are not using the Lifecycles library, you don’t need to update from 26.0.2." on the release notes, so I don' t use the 26.1.0.
am...@google.com <am...@google.com> #5
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.
[Deleted User] <[Deleted User]> #6
I have the same issue with support library 26.1.0 with CoordinatorLayout + RecyclerView or CoordinatorLayout + NestedScrollView
lo...@gmail.com <lo...@gmail.com> #7
I also face with the same problem and didn't fine out the solution. I just down the support design library to 25 and it will be fine. Hope you guys fix it ASAP. Thank you.
t....@gmail.com <t....@gmail.com> #8
For me, this issue presents itself after a 'fling', but not after a 'scroll'.
So you fling the RecyclerView, then wait as long as you like - the first item tap will not be recognised. Subsequent taps work just fine. But if you scroll the RecyclerView with no fling gesture, the first item tap will be recognised as expected.
I am also using a RecyclerView nested in a CoordinatorLayout (RV using layout_behavior = appbar_scrolling_view_behavior).
Support Library Version 26.1.0.
So you fling the RecyclerView, then wait as long as you like - the first item tap will not be recognised. Subsequent taps work just fine. But if you scroll the RecyclerView with no fling gesture, the first item tap will be recognised as expected.
I am also using a RecyclerView nested in a CoordinatorLayout (RV using layout_behavior = appbar_scrolling_view_behavior).
Support Library Version 26.1.0.
[Deleted User] <[Deleted User]> #9
Hello,
I am facing the same issue, it is working correctly with support version 26.0.0-alpha1 and 26.0.0-beta1, but the bug appears starting from the 26.0.0 release, and still present with the 26.0.1.
It seems to be associated with the NestedScrollingChild2 interface. With alpha and beta version, RecyclerView was implementing the NestedScrollingChild interface, and starting from 26.0.0 release, it is implementing NestedScrollingChild2 interface.
To reproduce, just create a sample ScrollingActivity from AndroidStudio, create an adapter holding a list of items, set a click listener on each item, scroll to the bottom of the list. When you are on the bottom of the list, fling from the bottom of your screen to the top and try to click to a specific item. It will do nothing (seems to stop the invisible fling), then if you click again, it will select your item.
I am facing the same issue, it is working correctly with support version 26.0.0-alpha1 and 26.0.0-beta1, but the bug appears starting from the 26.0.0 release, and still present with the 26.0.1.
It seems to be associated with the NestedScrollingChild2 interface. With alpha and beta version, RecyclerView was implementing the NestedScrollingChild interface, and starting from 26.0.0 release, it is implementing NestedScrollingChild2 interface.
To reproduce, just create a sample ScrollingActivity from AndroidStudio, create an adapter holding a list of items, set a click listener on each item, scroll to the bottom of the list. When you are on the bottom of the list, fling from the bottom of your screen to the top and try to click to a specific item. It will do nothing (seems to stop the invisible fling), then if you click again, it will select your item.
ad...@gmail.com <ad...@gmail.com> #10
I'm having the same issue. The issue appears first in 26.0.0-beta2 release, while 26.0.0-beta1 works as expected.
[Deleted User] <[Deleted User]> #11
I'm having the same issue. (26.0.0-beta2 ~ 27.0.0)
ch...@google.com <ch...@google.com> #12
Thanks for the patience. We have a fix being reviewed internally, but since it may take some time to be released publicly, he's a workaround: https://gist.github.com/chrisbanes/8391b5adb9ee42180893300850ed02f2
[Deleted User] <[Deleted User]> #13
Thank you Chris :)
ja...@gmail.com <ja...@gmail.com> #14
Hi Chris, I have a question why do we need to set the layout_behaivor to the AppBarLayout directly instead of to the scrollable? Or I'm getting something wrong?
ch...@google.com <ch...@google.com> #15
Here's an explanation for what the workaround does:
The original bug is caused by the change in 26.0.0 where flings can continue, even if the view is not actually moving. This was done to allow AppBarLayout to react to "resting" flings through nested scrolling.
The issue here is that once AppBarLayout has finished reacting to the resting fling (reach its end) the fling can still continue. Therefore even though nothing is moving on screen, when the user touches the screen they are just cancelling the invisible fling. Subsequent touches then do as expected (clicks, etc).
The fix here is more of a workaround than a proper fix. Here AppBarLayout detects when it has finished its fling handling, and then stops the nested scroll on the scrolling view (RV, etc).
The original bug is caused by the change in 26.0.0 where flings can continue, even if the view is not actually moving. This was done to allow AppBarLayout to react to "resting" flings through nested scrolling.
The issue here is that once AppBarLayout has finished reacting to the resting fling (reach its end) the fling can still continue. Therefore even though nothing is moving on screen, when the user touches the screen they are just cancelling the invisible fling. Subsequent touches then do as expected (clicks, etc).
The fix here is more of a workaround than a proper fix. Here AppBarLayout detects when it has finished its fling handling, and then stops the nested scroll on the scrolling view (RV, etc).
[Deleted User] <[Deleted User]> #16
Confirmed the workaround works great for us.
If you want to stuff this in a base class and know you're not setting any other behaviors on your appbarlayouts, you can put it in a base class in an overridden setLayoutParameters method
If you want to stuff this in a base class and know you're not setting any other behaviors on your appbarlayouts, you can put it in a base class in an overridden setLayoutParameters method
ch...@google.com <ch...@google.com> #17
If you already have a AppBarLayout subclass you can also do:
@CoordinatorLayout.DefaultBehavior(FixAppBarLayoutBehavior.class)
public CustomAppBarLayout extends AppBarLayout {
// ....
}
That way, you do not have to mess around with your layouts or the LayoutParams.
@CoordinatorLayout.DefaultBehavior(FixAppBarLayoutBehavior.class)
public CustomAppBarLayout extends AppBarLayout {
// ....
}
That way, you do not have to mess around with your layouts or the LayoutParams.
am...@google.com <am...@google.com> #18
The issue reported here has been fixed and it will be available in a future release.
ar...@google.com <ar...@google.com> #19
This issue is fixed and released in 27.0.1 version of support library.
az...@gmail.com <az...@gmail.com> #20
Are you sure this is fixed? Upgrading the support library to version 27.0.1 didn't help to get rid of the issue.
dg...@gmail.com <dg...@gmail.com> #21
Upgraded to support library version 27.0.1 and it did not fix the issue. Whenever RecyclerView is over scrolled, the first click still doesn't work.
[Deleted User] <[Deleted User]> #22
This issue is not solved. It does not working properly.
jo...@gmail.com <jo...@gmail.com> #23
Indeed, just tried with 27.0.1 and it's not fixed
dr...@gmail.com <dr...@gmail.com> #24
27.0.1, it's not fixed.
fa...@gmail.com <fa...@gmail.com> #25
27.0.1, it's not fixed, and I am using nest recyclerview
ps...@gmail.com <ps...@gmail.com> #26
It's a CoordinatorLayout thing I guess. The same thing happens with items inside NestedScrollView
dr...@gmail.com <dr...@gmail.com> #27
Please reopen this issue because it has not been fixed.
dr...@gmail.com <dr...@gmail.com> #28
al...@google.com <al...@google.com> #29
Issue was incorrectly tagged. This has been fixed internally but is not yet available in a public release.
am...@google.com <am...@google.com> #30
The issue reported here has been fixed internally and it will be available in a future support lib version.
ps...@gmail.com <ps...@gmail.com> #31
Still not fixed in 27.0.2z
de...@gmail.com <de...@gmail.com> #32
any progress? Still not fixed in 27.0.2
de...@gmail.com <de...@gmail.com> #33
Please reopen this issue because it has not been fixed.
pr...@gmail.com <pr...@gmail.com> #34
Please reopen this issue because it has not been fixed.
[Deleted User] <[Deleted User]> #35
Indeed, this is still not fixed.
ay...@gmail.com <ay...@gmail.com> #36
Please reopen this issue because it has not been fixed.
9g...@gmail.com <9g...@gmail.com> #37
reopen this issue because it has not been fixed.!!
[Deleted User] <[Deleted User]> #38
reopen this issue because it has not been fixed.!!
za...@gmail.com <za...@gmail.com> #39
Folks, the reason this fix wasn't released is because the design support library is now a separately maintained project. That project however has not seen a release in some time. Please subscribe/+1 to this issue instead - https://github.com/material-components/material-components-android/issues/50
sh...@gmail.com <sh...@gmail.com> #40
27.0.2 still not fixed.
ja...@gmail.com <ja...@gmail.com> #41
please fix it!
de...@gmail.com <de...@gmail.com> #42
Somewhere on the Internet is a workaround for this. Not cool but it works.
pe...@gmail.com <pe...@gmail.com> #43
Seeing the same issue with the latest support library 27.0.2
Hoping to see a proper solution, currently this is my workaround until then. Not the best workaround, but does work for me:
Override
public void onScrollStateChanged(final int state)
{
super.onScrollStateChanged(state);
if (state == RecyclerView.SCROLL_STATE_SETTLING)
{
this.stopScroll();
}
}
Hoping to see a proper solution, currently this is my workaround until then. Not the best workaround, but does work for me:
Override
public void onScrollStateChanged(final int state)
{
super.onScrollStateChanged(state);
if (state == RecyclerView.SCROLL_STATE_SETTLING)
{
this.stopScroll();
}
}
pe...@gmail.com <pe...@gmail.com> #44
Just adding some more details, hoping to be of use to Google developers. The issue in my scenario happens in a RecyclerView having as a root view a CoordinatorLayout. And the problem only happens after a fling scroll has finished reaching the top or bottom edge of the RecyclerView list. At such point the SCROLL_STATE_IDLE is received after a short delay (this delay is the actual problem). So this means that after the scroll has "visually" ended, since the RecyclerVIew doesn't have yet the idle scroll state due to such delay, touch events do not work on the list items until the RecyclerView gets into the idle state,.
hu...@gmail.com <hu...@gmail.com> #45
I still have had this issue when i replaced the 27.0.2.
[Deleted User] <[Deleted User]> #46
27.0.2 not fix
an...@gmail.com <an...@gmail.com> #47
27.0.2 still has this issue, please fix it.
[Deleted User] <[Deleted User]> #49
27.0.2 not fix the issue.
ha...@gmail.com <ha...@gmail.com> #50
Not fixed
ri...@gmail.com <ri...@gmail.com> #51
Anjing
fa...@gmail.com <fa...@gmail.com> #52
Are you ever gonna fix this? 5 months and still no fix
de...@gmail.com <de...@gmail.com> #53
+1k!
au...@google.com <au...@google.com> #54
shepshapard@ can you take a look at this?
sh...@google.com <sh...@google.com> #55
Yes, I've already looked into this and believe I've found the issue.
The issue is that after a fling event, the nested scrolling api has no way of informing the RecyclerView that a fling animation has reached the end of the scroll distance, and thus sometimes, the scroll animation is continuing in the background such that when the first tap occurs, it is interpreted as an interruption to the fling, which puts the RV back into its scrolling state as if the user started scrolling, and thus, the touch events don't propagate down to the child to cause a click to occur.
Some larger changes are needed to fix this (and at least one other) issue, and I'm in the midst of that work.
Sorry for the inconvenience.
The issue is that after a fling event, the nested scrolling api has no way of informing the RecyclerView that a fling animation has reached the end of the scroll distance, and thus sometimes, the scroll animation is continuing in the background such that when the first tap occurs, it is interpreted as an interruption to the fling, which puts the RV back into its scrolling state as if the user started scrolling, and thus, the touch events don't propagate down to the child to cause a click to occur.
Some larger changes are needed to fix this (and at least one other) issue, and I'm in the midst of that work.
Sorry for the inconvenience.
za...@gmail.com <za...@gmail.com> #56
The issue is that the material components team has seemingly abandoned the design support library and won't release new versions
dr...@gmail.com <dr...@gmail.com> #57
Have seen Support Library update to version 27.1.0.
May I ask in this version, fix this issue?
May I ask in this version, fix this issue?
sh...@google.com <sh...@google.com> #58
Unfortunately, this issue won't be fixed in the 27.1 release. I am actively working on it and will notify this thread when it is submitted (which means it will be in the following release). Sorry for the inconvenience!
sp...@gmail.com <sp...@gmail.com> #59
The same problem while I use RecyclerView in CoordinatorLayout.
sh...@google.com <sh...@google.com> #60
Yes. Sorry. The issue is actually caused by a lack of functionality in nested scrolling so you will see this issue when RV is nested in any other NestedScrollingParent.
When RecyclerView is flung, and it hits the bounds of it's scrollable distance and has a NestedScrollingParent, it continues to animate the fling so that the NestedScrollingParent might receive the events and scroll. RV has no way of knowing if any NestedScrollingParents have hit their bounds, and thus it continues the fling even if nothing is moving.
On top of that, when RV is flinging and is touched, it stops it's fling and prevents the touch event from causing a click, so that a touch meant to stop a fling doesn't cause a click.
Put those two things together and you get the perceived behavior that when an RV is flung, and stops, the next touch event doesn't click.
I'm pursuing a but can't make any promises as to when it will be available. Sorry for the inconvenience.
When RecyclerView is flung, and it hits the bounds of it's scrollable distance and has a NestedScrollingParent, it continues to animate the fling so that the NestedScrollingParent might receive the events and scroll. RV has no way of knowing if any NestedScrollingParents have hit their bounds, and thus it continues the fling even if nothing is moving.
On top of that, when RV is flinging and is touched, it stops it's fling and prevents the touch event from causing a click, so that a touch meant to stop a fling doesn't cause a click.
Put those two things together and you get the perceived behavior that when an RV is flung, and stops, the next touch event doesn't click.
I'm pursuing a but can't make any promises as to when it will be available. Sorry for the inconvenience.
ha...@gmail.com <ha...@gmail.com> #61
How come that the problem does not occur when I select older support library version? like the 25.3.1
pr...@gmail.com <pr...@gmail.com> #63
Not fix as in the newer versions. Can we bump up the priority of the issue because from the user's point of view clicking twice to is a bad experience?
su...@gmail.com <su...@gmail.com> #64
I have a similar issue but with the BottomNavigationView, is the fix proposed applicable to Views?
sh...@google.com <sh...@google.com> #65
I'm not absolutely sure that the proposed fix will also fix the issue you are having with BottomNavigationView, but it seems very likely that the root issue is still the same. I'm still trying to carve out time to address the issue but some work is in flight.
ny...@gmail.com <ny...@gmail.com> #66
27.0.2 do not fix the issue.
fa...@gmail.com <fa...@gmail.com> #67
this issue is still there in 27.1.1
le...@gmail.com <le...@gmail.com> #68
Also having this issue with 27.1.1
pi...@gmail.com <pi...@gmail.com> #69
The same
yi...@gmail.com <yi...@gmail.com> #70
same issue
de...@gmail.com <de...@gmail.com> #71
How is it possible that this bug is STILL not fixed??? It affect so many apps/developers/users. Crazy
t....@gmail.com <t....@gmail.com> #72
How is it possible that there are #71 'me too' comments? If you have nothing constructive to contribute, shut the fuck up and stop blowing up everyone's emails with your god damn complaints.
cn...@gmail.com <cn...@gmail.com> #73
Please fix it... It has been 6 months.
za...@gmail.com <za...@gmail.com> #74
This is fixed in material components, which is the successor to the design support library and currently released at 'com.google.android.material:material:1.0.0-beta01' and has been available for two months since Google I/O. Migrate to that if you want the fix: https://material.io/develop/android/
da...@gmail.com <da...@gmail.com> #75
Also having this issue with 27.1.1
[Deleted User] <[Deleted User]> #76
Using the version 27.1.1 but the issue is still there. Please fix it. Wait time is over.
ro...@gmail.com <ro...@gmail.com> #77
Just tried 28.0.0-rc01 and the problem is still there.
an...@googlemail.com <an...@googlemail.com> #78
#72 if there is no reaction from any google developer to this ridiculous situation.
sh...@google.com <sh...@google.com> #79
Sorry I have been unresponsive.
I am actively solving this issue. In fact, the CL that makes the necessary changes in RecyclerView has been submitted to aosp (as AndroidX is now developed there):https://android-review.googlesource.com/c/platform/frameworks/support/+/723649
The fix is coming by way of an update to nested scrolling and thus need to be implemented across multiple classes. For example, for the issue to be fixed when a RecyclerView is in a CoordinatorLayout with the AppBarLayout.Behavior, implementation has to be done in each of those classes.
Unfortunately the rollout of these changes is also going to take some time, but do know that we are taking as seriously as we can.
I am actively solving this issue. In fact, the CL that makes the necessary changes in RecyclerView has been submitted to aosp (as AndroidX is now developed there):
The fix is coming by way of an update to nested scrolling and thus need to be implemented across multiple classes. For example, for the issue to be fixed when a RecyclerView is in a CoordinatorLayout with the AppBarLayout.Behavior, implementation has to be done in each of those classes.
Unfortunately the rollout of these changes is also going to take some time, but do know that we are taking as seriously as we can.
fr...@gmail.com <fr...@gmail.com> #80
Please give me the solution
sh...@google.com <sh...@google.com> #81
Unfortunately, the solution is not something you can easily implement on your own and instead really must be implemented in the libraries themselves. But like I said the solution is known and the work is actually nearly complete. Unfortunately, even when it is complete, we will have to wait for it to actually be released. Sorry for the delay!
sh...@gmail.com <sh...@gmail.com> #83
Not working for me on V27.1.1
I've tried both java and xml ways but in vain.
Checked on emulator running on 5.0 and physical device running on 7.1.1
Any ideas ?
I've tried both java and xml ways but in vain.
Checked on emulator running on 5.0 and physical device running on 7.1.1
Any ideas ?
sh...@gmail.com <sh...@gmail.com> #84
It is weird that this bug is a year old and has not been addressed properly by Google yet.
ss...@gmail.com <ss...@gmail.com> #85
Still an issue in 28.0.0. Are there any reliable workarounds for this issue?
am...@gmail.com <am...@gmail.com> #87
I'm migrated to AndroidX and seem that this issue are fixed
am...@google.com <am...@google.com>
pa...@gmail.com <pa...@gmail.com> #88
I do not know why I am not getting any callback on time. I am hiding some view on scroll-start of recycler view. But the problem is I am not getting it on time and my implementation causes few bugs.
Dear Google developers, can you please take it on priority?
Dear Google developers, can you please take it on priority?
we...@gmail.com <we...@gmail.com> #89
Still seeing this issue in androidx.core 1.1.0-alpha01 with BottomNavigationView.
kp...@gmail.com <kp...@gmail.com> #90
This issue was fixed for me when started using recyclerview:1.1.0-alpha01 with coordinatorlayout:1.1.0-alpha01.
I think it is related with NestedScrollingChild3 and NestedScrollingParent3 and since 1.1.0-alpha01 RecyclerView and CoordinatorLayout implements those.
I think it is related with NestedScrollingChild3 and NestedScrollingParent3 and since 1.1.0-alpha01 RecyclerView and CoordinatorLayout implements those.
sh...@google.com <sh...@google.com> #91
I'm glad to hear it given that NestedScrollingChild3 and NestedScrollingParent3 were created and are implemented to solve this very issue! There is one thing that isn't implemented yet due to some complexity: updating AppBarLayout.Behavior... so even if you use recyclerview:1.1.0-alpha01 with coordinatorlayout:1.1.0-alpha01 right now, if you also use AppBarLayout.Behavior to collapse the AppBar, then the underlying issue will return and this bug will present itself.
sh...@google.com <sh...@google.com> #92
Via the new Nested Scrolling 3 API, and it's implementation across various libraries:
androidx.core 1.1.0-alpha01
androidx.appcompat 1.1.0-alpha01
androidx.coordinatorlayout 1.1.0-alpha01
androidx.recyclerview 1.1.0-alpha01
androidx.swiperefreshlayout 1.1.0-alpha01
(and an upcoming release of the android material design library)
This issue should be fixed!
I'm closing it, but do let me know if it seems to still be happening!
androidx.core 1.1.0-alpha01
androidx.appcompat 1.1.0-alpha01
androidx.coordinatorlayout 1.1.0-alpha01
androidx.recyclerview 1.1.0-alpha01
androidx.swiperefreshlayout 1.1.0-alpha01
(and an upcoming release of the android material design library)
This issue should be fixed!
I'm closing it, but do let me know if it seems to still be happening!
pa...@outlook.com <pa...@outlook.com> #93
It is still happening under this specific scenario:
This is a BottomSheet with a NestedScrollView, it does not contain any RecyclerView:
<?xml version="1.0" encoding="utf-8"?>
<androidx.coordinatorlayout.widget.CoordinatorLayout
xmlns:android="http://schemas.android.com/apk/res/android "
xmlns:app="http://schemas.android.com/apk/res-auto "
android:layout_width="match_parent"
android:layout_height="match_parent"
android:clipChildren="false">
<com.google.android.material.appbar.AppBarLayout
android:layout_width="match_parent"
android:layout_height="wrap_content">
<!--Other views and tested with and without a Toolbar inside-->
</com.google.android.material.appbar.AppBarLayout>
<androidx.core.widget.NestedScrollView
android:layout_width="match_parent"
android:layout_height="match_parent"
android:background="@color/white"
app:layout_behavior="@string/appbar_scrolling_view_behavior">
<LinearLayout
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:orientation="vertical"
android:paddingBottom="8dp"
android:paddingTop="8dp">
<!--Enough views to create a scrollable area-->
</LinearLayout>
</androidx.core.widget.NestedScrollView>
</androidx.coordinatorlayout.widget.CoordinatorLayout>
In this scenario (with or without a Toolbar view in the AppBarLayout parent) whenever you scroll the NestedScrollView to the top or to the bottom and try to tap on any items inside the LinearLayout the first tap will always fail to initiate the expected action, forcing you to do a second tap since after the first one the taps start working. This happens whenever you scroll to the top or bottom of the NestedScrollView every single time, even after you tap for a second or n times.
I am using the library versions or most up to date (a couple were already updated since then) the Assignee listed in his last reply.
This is a BottomSheet with a NestedScrollView, it does not contain any RecyclerView:
<?xml version="1.0" encoding="utf-8"?>
<androidx.coordinatorlayout.widget.CoordinatorLayout
xmlns:android="
xmlns:app="
android:layout_width="match_parent"
android:layout_height="match_parent"
android:clipChildren="false">
<com.google.android.material.appbar.AppBarLayout
android:layout_width="match_parent"
android:layout_height="wrap_content">
<!--Other views and tested with and without a Toolbar inside-->
</com.google.android.material.appbar.AppBarLayout>
<androidx.core.widget.NestedScrollView
android:layout_width="match_parent"
android:layout_height="match_parent"
android:background="@color/white"
app:layout_behavior="@string/appbar_scrolling_view_behavior">
<LinearLayout
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:orientation="vertical"
android:paddingBottom="8dp"
android:paddingTop="8dp">
<!--Enough views to create a scrollable area-->
</LinearLayout>
</androidx.core.widget.NestedScrollView>
</androidx.coordinatorlayout.widget.CoordinatorLayout>
In this scenario (with or without a Toolbar view in the AppBarLayout parent) whenever you scroll the NestedScrollView to the top or to the bottom and try to tap on any items inside the LinearLayout the first tap will always fail to initiate the expected action, forcing you to do a second tap since after the first one the taps start working. This happens whenever you scroll to the top or bottom of the NestedScrollView every single time, even after you tap for a second or n times.
I am using the library versions or most up to date (a couple were already updated since then) the Assignee listed in his last reply.
sh...@google.com <sh...@google.com> #94
We actually just noticed this issue ourselves and it is actually getting addressed right now in the BottomSheet code. Sorry about that. I have also communicated with the Android Material Design team to make sure other code doesn't need to be updated as well.
There isn't a public bug that I'm aware of that is tracking that precise work, but know that your specific issue will be fixed in an upcoming release of the Android Material Design library.
There isn't a public bug that I'm aware of that is tracking that precise work, but know that your specific issue will be fixed in an upcoming release of the Android Material Design library.
pa...@outlook.com <pa...@outlook.com> #95
I appreciate the update. Please let us know when it is fixed in this thread since there isn't a dedicated thread for that specific bug.
me...@google.com <me...@google.com> #96
Material Design Library is actively updating this for BSB, you may track the progress here: b/128698671
yq...@gmail.com <yq...@gmail.com> #97
I'm having the same problem with a RecyclerView in MotionLayout, so I created issue for it.
https://issuetracker.google.com/issues/128914828
pv...@gmail.com <pv...@gmail.com> #98
I'm using recycler view in bottom sheet and this issue is not fixed.
recyclerview-v7:28.0.0
recyclerview-v7:28.0.0
vz...@gmail.com <vz...@gmail.com> #99
we are using 28.0.0, the problem is still there.
sh...@google.com <sh...@google.com> #100
28.0 was the last release of RecyclerView in the support library packages and should be considered deprecated:
https://developer.android.com/reference/android/support/v7/widget/RecyclerView
The AndroidX version of RecyclerView picks up where that version left off and is currently supported:
https://developer.android.com/jetpack/androidx/releases/recyclerview
The AndroidX version of RecyclerView picks up where that version left off and is currently supported:
sh...@google.com <sh...@google.com> #101
See comment #92 .
sa...@gmail.com <sa...@gmail.com> #102
For those having problems with bottom sheet, you need to bump your material version to at least 1.1.0-alpha05
[Deleted User] <[Deleted User]> #103
I am getting same issue with androidx.recyclerview:recyclerview:1.1.0.
[Deleted User] <[Deleted User]> #104
Bump, same issue on androix.recyclerview:recyclerview:1.1.0.
sh...@google.com <sh...@google.com> #105
I will need a minimal repro case for me to be able to look into this any further. Thanks.
te...@gmail.com <te...@gmail.com> #106
One was given to you in the first post almost 2 and a half years ago. *facepalm*. I wonder why us developers even bother logging bugs with Google anymore...
sh...@google.com <sh...@google.com> #107
What I meant was that I believe this bug to be fixed given all of the changes that have been done to fix it. In making the changes, I looked for a holistic solution and thus think it was indeed holistic, but if some still find that it does not work, it would be very helpful for me to see a demonstration.
ma...@gmail.com <ma...@gmail.com> #108
Also reproed while using MotionLayout :(
ma...@gmail.com <ma...@gmail.com> #109
Also reproed while using MotionLayout :(
but it's working fine if I double tap it quickly
but it's working fine if I double tap it quickly
sh...@google.com <sh...@google.com> #110
I would need more information about an issue with MotionLayout. Can you please file a separate bug with details including a minimal repro case?
bo...@gmail.com <bo...@gmail.com> #111
Updated my AndroidX dependencies and fixed the issue with appbarlayout/bottomnav/recyclerview. Did not try out MotionLayout
Description
Version used: 26.0.2
Theme used: Theme.AppCompat.NoActionBar
Devices/Android versions reproduced on: AVD API 25
I just upgraded to API 26 and support library 26.0.2. But I found that my RecyclerView items is not clickable right after the scrolling. If you wait for a second, it will work. But if you click the item immediately, it won't. Even if the RecyclerView is not scrolling at all(e.g. has scrolled to the top).
When I downgraded to support library 25.4.0 everything goes fine again. The key point is that my RecyclerView is in a CoordinatorLayout and has a SCROLL_FLAG_SCROLL flag on my Toolbar of the AppBarLayout. If I don't use this flag, then this problem will disappear.
I've tried to add focusable="false" to the CoordinatorLayout but still had no luck.
Is there any way to disable this behavior? Because it's really annoying to click twice to trigger the click event.
I think the problem is the scrollState of the RecyclerView. When it's stopped scrolling, it's not changed to SCROLL_STATE_IDLE immediately. Looking into the source code of RecyclerView, I found there's a ViewFlinger controlling the scroll state. When I fling down to scroll to the top, it's not calling setScrollState(SCROLL_STATE_IDLE) immediately. Instead, it wait for a while to trigger this method. The more fast I fling, the more time I need to wait. It just like the RecyclerView is still scrolling in the background. Because the scroller.isFinished() doesn't return true right after the RecyclerView stop scrolling when it touched the top. Maybe it's a bug of the RecyclerView when it's in a CoordinatorLayout.
The attachment is a screen recording of this behavior.
<android.support.design.widget.CoordinatorLayout
android:id="@+id/coordinateLayout"
android:layout_width="match_parent"
android:layout_height="match_parent">
<android.support.design.widget.AppBarLayout
android:id="@+id/fragmentAppBar"
android:layout_width="match_parent"
android:layout_height="wrap_content"
app:elevation="0dp"
android:background="@null">
<include
android:id="@+id/dynamicActionBarHolder"
layout="@layout/dynamic_action_bar"/>
</android.support.design.widget.AppBarLayout>
<android.support.v4.widget.SwipeRefreshLayout
android:id="@+id/pullToRefreshMailRecycler"
android:layout_width="match_parent"
android:layout_height="match_parent"
app:layout_behavior="@string/appbar_scrolling_view_behavior">
<android.support.v7.widget.RecyclerView
android:id="@+id/mailRecyclerView"
android:layout_width="match_parent"
android:layout_height="match_parent"/>
</android.support.v4.widget.SwipeRefreshLayout>
</android.support.design.widget.CoordinatorLayout>
layout/dynamic_action_bar.xml
<FrameLayout xmlns:android="
xmlns:app="
android:layout_width="match_parent"
android:layout_height="?attr/actionBarSize"
app:layout_scrollFlags="scroll"
android:clickable="true"
android:background="?theme.dynamicActionBarBackground">
<ImageButton
android:id="@+id/dynamicAcbMenuIcon"
android:layout_width="?attr/actionBarSize"
android:layout_height="?attr/actionBarSize"
android:background="@drawable/article_explicit_button_background"
android:src="?theme.menuIcon"/>
<RelativeLayout
android:id="@+id/dynamicAcbTitleHolder"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:layout_marginStart="?attr/actionBarSize"
android:paddingTop="5dp"
android:paddingBottom="5dp"
android:paddingEnd="5dp"
android:layout_gravity="center_vertical">
<TextView
android:id="@+id/dynamicAcbTitle"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:singleLine="true"
android:textSize="@dimen/action_bar_title_portrait_size"
android:textColor="?theme.listItemTitleColor"
android:ellipsize="end"
android:text="ActionBar"/>
<TextView
android:id="@+id/dynamicAcbSubtitle"
android:layout_below="@+id/dynamicAcbTitle"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:singleLine="true"
android:textSize="@dimen/action_bar_subtitle_portrait_size"
android:textColor="?theme.listItemTitleColor"
android:ellipsize="end"
android:text="If you say so"/>
</RelativeLayout>
</FrameLayout>