Fixed
Status Update
No update yet.
Comments
uc...@google.com
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.
je...@google.com
ga...@google.com
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.
ha...@googlemail.com
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.
ha...@googlemail.com
I have the same issue with support library 26.1.0 with CoordinatorLayout + RecyclerView or CoordinatorLayout + NestedScrollView
ha...@googlemail.com
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.
je...@google.com
ga...@google.com
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.
ma...@gmail.com
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.
ga...@google.com
I'm having the same issue. The issue appears first in 26.0.0-beta2 release, while 26.0.0-beta1 works as expected.
ma...@gmail.com
I'm having the same issue. (26.0.0-beta2 ~ 27.0.0)
ga...@google.com
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
ma...@gmail.com
Thank you Chris :)
ma...@gmail.com
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?
ga...@google.com
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).
ga...@google.com
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
je...@google.com
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.
ga...@google.com
The issue reported here has been fixed and it will be available in a future release.
ma...@gmail.com
This issue is fixed and released in 27.0.1 version of support library.
ga...@google.com
Are you sure this is fixed? Upgrading the support library to version 27.0.1 didn't help to get rid of the issue.
ma...@gmail.com
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.
ga...@google.com
This issue is not solved. It does not working properly.
ma...@gmail.com
Indeed, just tried with 27.0.1 and it's not fixed
ga...@google.com
27.0.1, it's not fixed.
ma...@gmail.com
27.0.1, it's not fixed， and I am using nest recyclerview
ga...@google.com
ma...@gmail.com
It's a CoordinatorLayout thing I guess. The same thing happens with items inside NestedScrollView
ga...@google.com
Please reopen this issue because it has not been fixed.
jw...@gmail.com
ga...@google.com
Issue was incorrectly tagged. This has been fixed internally but is not yet available in a public release.
dr...@gmail.com
The issue reported here has been fixed internally and it will be available in a future support lib version.
jw...@gmail.com
Still not fixed in 27.0.2z
dr...@gmail.com
any progress? Still not fixed in 27.0.2
ma...@gmail.com
Please reopen this issue because it has not been fixed.
ga...@google.com
Please reopen this issue because it has not been fixed.
ma...@gmail.com
Indeed, this is still not fixed.
ga...@google.com
Please reopen this issue because it has not been fixed.
ma...@gmail.com
reopen this issue because it has not been fixed.!!
ga...@google.com
reopen this issue because it has not been fixed.!!
ma...@gmail.com
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
ga...@google.com
27.0.2 still not fixed.
ma...@gmail.com
please fix it!
ga...@google.com
Somewhere on the Internet is a workaround for this. Not cool but it works.
ja...@gmail.com
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();
}
}
ja...@gmail.com
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,.
yo...@gmail.com
I still have had this issue when i replaced the 27.0.2.
ja...@gmail.com
27.0.2 not fix
st...@gmail.com
27.0.2 still has this issue, please fix it.
ja...@gmail.com
27.0.2 not fix the issue.
dr...@gmail.com
Not fixed
st...@gmail.com
Anjing
st...@gmail.com
Are you ever gonna fix this? 5 months and still no fix
ja...@gmail.com
shepshapard@ can you take a look at this?
[Deleted User] <[Deleted User]>
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
The issue is that the material components team has seemingly abandoned the design support library and won't release new versions
[Deleted User] <[Deleted User]>
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?
le...@gmail.com
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!
ga...@google.com
The same problem while I use RecyclerView in CoordinatorLayout.
ja...@gmail.com
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.
vy...@pinterest.com
How come that the problem does not occur when I select older support library version? like the 25.3.1
cm...@google.com
cm...@google.com
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?
sz...@gmail.com
I have a similar issue but with the BottomNavigationView, is the fix proposed applicable to Views?
zt...@gmail.com
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.
cm...@google.com
ja...@gmail.com
this issue is still there in 27.1.1
an...@gmail.com
Also having this issue with 27.1.1
le...@gmail.com
The same
[Deleted User] <[Deleted User]>
same issue
[Deleted User] <[Deleted User]>
How is it possible that this bug is STILL not fixed??? It affect so many apps/developers/users. Crazy
[Deleted User] <[Deleted User]>
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.
ga...@google.com
Please fix it... It has been 6 months.
ma...@gmail.com
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/
ga...@google.com
Also having this issue with 27.1.1
st...@gmail.com
Using the version 27.1.1 but the issue is still there. Please fix it. Wait time is over.
fu...@gmail.com
Just tried 28.0.0-rc01 and the problem is still there.
[Deleted User] <[Deleted User]>
#72 if there is no reaction from any google developer to this ridiculous situation.
[Deleted User] <[Deleted User]>
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.
[Deleted User] <[Deleted User]>
Please give me the solution
[Deleted User] <[Deleted User]>
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!
[Deleted User] <[Deleted User]>
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 ?
ga...@google.com
It is weird that this bug is a year old and has not been addressed properly by Google yet.
pe...@layer.com.c-02odbdyf.appstempdomain.goog
Still an issue in 28.0.0. Are there any reliable workarounds for this issue?
ga...@google.com
I'm migrated to AndroidX and seem that this issue are fixed
pe...@layer.com.c-02odbdyf.appstempdomain.goog
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?
Description
Build #AI-171.3870562, built on April 1, 2017
JRE: 1.8.0_112-release-b736 x86_64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
gradle-3.4.1
classpath 'com.android.tools.build:gradle:2.4.0-alpha4'
buildTools : '25.0.1',
compileSdk : 25,
javaVersion: JavaVersion.VERSION_1_8,
minSdk : 16,
targetSdk : 25
Multidex is setup and works fine (compile, assemble and espresso test) with:
classpath 'com.android.tools.build:gradle:2.3.0'
When we bump up to 2.4 alpha 4 we get multidex issue when we try to run the tests:
(I repeat multidex is setup properly and everything works fine on plugin 2.3.0)
This is a scaffold-like very close to our project setup that I created to reproduce various gradle issues we encounter with our enteprise project:
(sadly I did not update it and maintain it in some time I can refresh it if you really need it or feel free to fork or PR)
This is the stacktrace of the issue
This is the command I ran on our project (should be the same on example project I attached)
./gradlew clean connectedNonpayUnitedStatesBleedingDebugAndroidTest --stacktrace
but I repeat I do not know yet does that project compiles even with the new plugin I can update it later on if you need it.