Assigned
Status Update
No update yet.
Comments
ja...@gmail.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.
mi...@gmail.com
I am facing the same issue with 26.1.0 as well.
pa...@gmail.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.
br...@gmail.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.
ja...@gmail.com
I have the same issue with support library 26.1.0 with CoordinatorLayout + RecyclerView or CoordinatorLayout + NestedScrollView
ra...@gmail.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.
al...@android.com
ma...@gmail.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.
[Deleted User] <[Deleted User]>
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.
mi...@gmail.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.
[Deleted User] <[Deleted User]>
I'm having the same issue. (26.0.0-beta2 ~ 27.0.0)
[Deleted User] <[Deleted User]>
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]>
Thank you Chris :)
bo...@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?
[Deleted User] <[Deleted User]>
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).
ma...@gmail.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
ja...@gmail.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.
mo...@gmail.com
The issue reported here has been fixed and it will be available in a future release.
m....@gmail.com
This issue is fixed and released in 27.0.1 version of support library.
de...@gmail.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.
me...@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.
kr...@gmail.com
This issue is not solved. It does not working properly.
su...@gmail.com
Indeed, just tried with 27.0.1 and it's not fixed
ar...@connectmedica.com
27.0.1, it's not fixed.
ia...@gmail.com
27.0.1, it's not fixed， and I am using nest recyclerview
ke...@pinxterapp.com
It's a CoordinatorLayout thing I guess. The same thing happens with items inside NestedScrollView
ni...@google.com
[Deleted User] <[Deleted User]>
Please reopen this issue because it has not been fixed.
ja...@gmail.com
[Deleted User] <[Deleted User]>
Issue was incorrectly tagged. This has been fixed internally but is not yet available in a public release.
ru...@gmail.com
The issue reported here has been fixed internally and it will be available in a future support lib version.
sa...@gmail.com
Still not fixed in 27.0.2z
Description
However, for my app, the derived colors for both are noticeably different than the rest of my application. While the functionality of custom tabs is winning over the designer, they are not happy with the visual result.
Therefore, I'd like to be able to specify the status bar color to use with the custom tab (ie the primaryColorDark from my application). Seems reasonable if the developer doesn't specify a status bar color it uses the derived color as it does today.
As well I'd like to control the icon tint in the tool bar for the default "close" and "overflow" icons. While, specifying my own bitmap works around the "close" icon, the overflow icon tint is still controlled by the custom tab and may not match the overall theme.