Infeasible
Status Update
Comments
ar...@google.com <ar...@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.
wo...@gmail.com <wo...@gmail.com> #3
I am facing the same issue with 26.1.0 as well.
ar...@google.com <ar...@google.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.
ar...@google.com <ar...@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.
ha...@gmail.com <ha...@gmail.com> #6
I have the same issue with support library 26.1.0 with CoordinatorLayout + RecyclerView or CoordinatorLayout + NestedScrollView
ar...@gmail.com <ar...@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.
kv...@gmail.com <kv...@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.
ha...@gmail.com <ha...@gmail.com> #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.
[Deleted User] <[Deleted User]> #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.
ar...@google.com <ar...@google.com> #11
I'm having the same issue. (26.0.0-beta2 ~ 27.0.0)
ch...@beyls.net <ch...@beyls.net> #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
ch...@beyls.net <ch...@beyls.net> #13
Thank you Chris :)
[Deleted User] <[Deleted User]> #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...@beyls.net <ch...@beyls.net> #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).
ar...@google.com <ar...@google.com> #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
ar...@google.com <ar...@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.
ch...@beyls.net <ch...@beyls.net> #18
The issue reported here has been fixed and it will be available in a future release.
ch...@google.com <ch...@google.com> #19
This issue is fixed and released in 27.0.1 version of support library.
ch...@beyls.net <ch...@beyls.net> #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.
ar...@google.com <ar...@google.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.
Description
The referenced issue is closed because the bug was fixed in an older release. However the bug reappears in the support library 25.x again and there are a lot of comments that are asking for opening the ticket.
But apparently no maintainer is reading closed tickets so I'm opening this to pull the attention there.