The item inside RecyclerView can't be clicked right after scrolling [66996774]

Fixed

Bug

[AOSP] assigned

Status Update

No update yet.

Description

ki...@gmail.com

created issue #1

Sep 27, 2017 05:06PM

Library used (support-v4, appcompat-v7, ...):support-v4, appcompat-v7, design, cardview-v7, recyclerview-v7, customtabs
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="

http://schemas.android.com/apk/res/android"
xmlns:app="

http://schemas.android.com/apk/res-auto"
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>

demo.mov

20 MB

Download

Comments

am...@google.com <am...@google.com> Sep 28, 2017 03:49AM

Assigned to am...@google.com.

am...@google.com <am...@google.com> #2Sep 28, 2017 10:41AM

Thanks for filing the issue.

This is a particularly hard device to come by - do you happen to have access to the device? If so could you provide us with the output of: adb shell dumpsys media.camera > info.txt

Thanks!

ca...@gmail.com <ca...@gmail.com> #3Sep 29, 2017 12:58AM

Similar stacktrace reported to the email group

Stacktrace:

Caused by: java.lang.IllegalArgumentException: Can not get supported output size under supported maximum for the format: 34
at androidx.camera.camera2.internal.SupportedSurfaceCombination.getSupportedOutputSizes(SupportedSurfaceCombination.java:355)
at androidx.camera.camera2.internal.SupportedSurfaceCombination.getSuggestedResolutions(SupportedSurfaceCombination.java:197)
at androidx.camera.camera2.internal.Camera2DeviceSurfaceManager.getSuggestedResolutions(Camera2DeviceSurfaceManager.java:198)
at androidx.camera.core.CameraX.calculateSuggestedResolutions(CameraX.java:943)
at androidx.camera.core.CameraX.bindToLifecycle(CameraX.java:293)
at androidx.camera.lifecycle.ProcessCameraProvider.bindToLifecycle(ProcessCameraProvider.java:227)

Below are some findings based on our debugging

When Dex is connected

previewConfig.getMaxResolution() is returning "731x411" as maxSize.

Inside Preview.Builder.build() -> Default_MAX_resolution is set to "CameraX.getSurfaceManager().getPreviewSize()" which is 731x411
this is being picked as maxSize.

While rendering maxSize is 731x411 and minSize is 640x480 and below are available outputSizes
0 = {Size@11860} "4032x3024"
1 = {Size@11861} "3984x2988"
2 = {Size@11862} "4032x2268"
3 = {Size@11863} "3024x3024"
4 = {Size@11864} "2976x2976"
5 = {Size@11865} "3840x2160"
6 = {Size@11866} "3264x2448"
7 = {Size@11867} "4032x1960"
8 = {Size@11868} "2880x2160"
9 = {Size@11869} "3264x1836"
10 = {Size@11870} "2160x2160"
11 = {Size@11871} "2560x1440"
12 = {Size@11872} "2224x1080"
13 = {Size@11873} "2048x1152"
14 = {Size@11874} "1920x1080"
15 = {Size@11875} "1440x1080"
16 = {Size@11876} "1088x1088"
17 = {Size@11877} "1280x720"
18 = {Size@11878} "1024x768"
19 = {Size@11879} "1056x704"
20 = {Size@11880} "960x720"
21 = {Size@11881} "960x540"
22 = {Size@11882} "720x720"
23 = {Size@11883} "800x450"
24 = {Size@11884} "720x480"
25 = {Size@11885} "640x480"
26 = {Size@11886} "352x288"
27 = {Size@11887} "320x240"
28 = {Size@11888} "256x144"
29 = {Size@11889} "176x144"

and couldn't find any size in this range.

When Dex not connected

minsize = 640x480
maxsize = 1920x1080
0 = {Size@11836} "4032x3024"
1 = {Size@11837} "3984x2988"
2 = {Size@11838} "4032x2268"
3 = {Size@11839} "3024x3024"
4 = {Size@11840} "2976x2976"
5 = {Size@11841} "3840x2160"
6 = {Size@11842} "3264x2448"
7 = {Size@11843} "4032x1960"
8 = {Size@11844} "2880x2160"
9 = {Size@11845} "3264x1836"
10 = {Size@11846} "2160x2160"
11 = {Size@11847} "2560x1440"
12 = {Size@11848} "2224x1080"
13 = {Size@11849} "2048x1152"
14 = {Size@11850} "1920x1080"
15 = {Size@11851} "1440x1080"
16 = {Size@11852} "1088x1088"
17 = {Size@11853} "1280x720"
18 = {Size@11854} "1024x768"
19 = {Size@11855} "1056x704"
20 = {Size@11856} "960x720"
21 = {Size@11857} "960x540"
22 = {Size@11858} "720x720"
23 = {Size@11859} "800x450"
24 = {Size@11860} "720x480"
25 = {Size@11861} "640x480"
26 = {Size@11862} "352x288"
27 = {Size@11863} "320x240"
28 = {Size@11864} "256x144"
29 = {Size@11865} "176x144"
and we have 12 available sizes in this range

Camera2DeviceSurfaceManager.java:: getPreviewSize()
mCameraSupportedSurfaceCombinationMap.get(cameraId).getSurfaceDefinition().getPreviewSize() = "1920x1080"
cameraId=0

ki...@gmail.com <ki...@gmail.com> #4Sep 30, 2017 07:16AM

Hi virifi129,

The issue root cause is that CameraX will default filter out sizes smaller than 640x480. For Preview, the max size will be limited to under display size. I checked the HW spec info for the issue related devices. Display size of FUJITSU F-04J/F-05J is 360x640. That will result int that no size exists in the conditions that is larger or equal to 640x480 and smaller or equal to 360x640.

A temporary workaround for this situation is to use Preview.Builder#setTargetResolution() to set a size smaller than 640x480 to bypass the problem.

For device FUJITSU arrowsM04, I checked its HW spec info and its display size I found is 1280x720. It seems that the problem should not exist in the device.
Could you confirm that the problem exist on arrowsM04 device? What will be the returned value when using Display#getRealSize to obtain the display size?

TestApplication.zip

34 MB

Download

am...@google.com <am...@google.com> #5Oct 3, 2017 09:40AM

Sorry for the late reply.

> A temporary workaround for this situation is to use Preview.Builder#setTargetResolution() to set a size smaller than 640x480 to bypass the problem.

OK. I will try it.

> Could you confirm that the problem exist on arrowsM04 device?

We receive the crash report (Crashlytics) that this crash has occurred on arrowsM04.
We don't have this device so we can't confirm that the problem really exist on arrowsM04.

> What will be the returned value when using Display#getRealSize to obtain the display size?

We can't investigate it for the same reason.

Thank you.

[Deleted User] <[Deleted User]> #6Oct 4, 2017 02:50AM

Root cause:
This issue happened on devices that the display size is smaller than 640x480. In original auto-resolution mechanism, supported sizes smaller than 640x480 will be default filter out.

The auto-resolution mechanism encodes the guaranteed configurations tables in CameraDevice#createCaptureSession(SessionConfiguration). It defines that the PREVIEW size is the small one of the device display size and 1080p. The PREVIEW size will be the maximal size limitation for Preview use case. The reason it limits the size to display size and 1080p is the stream output in display size or 1080p has been able to provide good enough preview quality. Therefore, auto-resolution mechanism will limit the selected size to be smaller than the small one of the device display size and 1080p.

With above two conditions, in this issue, all sizes smaller than 640x480 have been filter out, therefore, there is no size smaller than the display size 320x240 can be selected to use. And cause the exception.

Solution:
When the display size is smaller than 640x480, auto-resolution mechanism won't filter out those small sizes smaller than 640x480. This makes those small size be left and can be selected for the Preview use case on small display devices.

The solution has been merged and will be included in next CameraX release.

lo...@gmail.com <lo...@gmail.com> #7Oct 4, 2017 02:51AM

Hello.

This crash still occurs.

CAMERAX VERSION: 1.0.0-beta4
ANDROID OS BUILD NUMBER: Android 7.1.1
DEVICE NAME: FUJITSU F-02H

We receive following crash report from FUJITSU F-02H. So far We have received this crash report only from F-02H.

java.lang.IllegalArgumentException
Can not get supported output size under supported maximum for the format: 34

androidx.camera.camera2.internal.SupportedSurfaceCombination.getSupportedOutputSizes (SupportedSurfaceCombination.java:349)
androidx.camera.camera2.internal.SupportedSurfaceCombination.getSuggestedResolutions (SupportedSurfaceCombination.java:197)
androidx.camera.camera2.internal.Camera2DeviceSurfaceManager.getSuggestedResolutions (Camera2DeviceSurfaceManager.java:198)
androidx.camera.core.CameraX.calculateSuggestedResolutions (CameraX.java:949)
androidx.camera.core.CameraX.bindToLifecycle (CameraX.java:351)
androidx.camera.lifecycle.ProcessCameraProvider.bindToLifecycle (ProcessCameraProvider.java:230)
(our application's package name).CameraFragment.bindCameraUseCases (CameraFragment.java:174)

t....@gmail.com <t....@gmail.com> #8Oct 10, 2017 03:58AM

Hi virifi129,

Could you help to provide the following information to clarify the issue?
1. Is the full name of the device Fujitsu Arrows NX F-02H that has a 1440x2560 display?
2. Please help to provide the supported output sizes of ImageFormat.PRIVATE that is obtained by StreamConfigurationMap#getOutputSizes(int).

[Deleted User] <[Deleted User]> #9Oct 21, 2017 02:18PM

Is the full name of the device Fujitsu Arrows NX F-02H that has a 1440x2560 display?

Yes

Please help to provide the supported output sizes of ImageFormat.PRIVATE that is obtained by StreamConfigurationMap#getOutputSizes(int).

Since we don't have this device, we'll try to collect this information in the next version of our app. The next version will be released later this month.

ad...@gmail.com <ad...@gmail.com> #10Oct 30, 2017 12:35PM

Hello.

Please help to provide the supported output sizes of ImageFormat.PRIVATE that is obtained by StreamConfigurationMap#getOutputSizes(int).

We have collected the output of the device where the crash occurs.

Device1

Model : arrows Be F-05J
Android Version : 7.1.1
Supported output sizes of ImageFormat.PRIVATE

CameraId 0: 480x480
CameraId 1: 2048x1536 ,1920x1080 ,1280x720 ,960x720 ,640x480 ,320x240 ,176x144

Device2

Model : Fujitsu arrows M04
Android Version : 7.1.1
Supported output sizes of ImageFormat.PRIVATE

CameraId 0: 480x480
CameraId 1: 2048x1536 ,1920x1080 ,1280x720 ,960x720 ,640x480 ,320x240 ,176x144

Additional Information

CameraX version : 1.0.0-beta04

We collect the supported output sizes by following code.

val errorString = buildString {
      append("The supported output sizes of ImageFormat.PRIVATE: ")

      (requireContext().getSystemService(Context.CAMERA_SERVICE) as CameraManager).apply {

        cameraIdList.forEachIndexed { index, cameraId ->
          val msg = if (VERSION.SDK_INT >= VERSION_CODES.M) {
            val configurationMap =
              getCameraCharacteristics(cameraId).get(CameraCharacteristics.SCALER_STREAM_CONFIGURATION_MAP)
            val sizes = configurationMap?.getOutputSizes(ImageFormat.PRIVATE)
            "CameraId $index: ${sizes?.joinToString(" ,")}"
          } else {
            "CameraId $index: This device version is under M."
          }
          append(msg)
        }
      }
    }

[Deleted User] <[Deleted User]> #11Nov 2, 2017 07:35AM

Hello. Any updates?

ch...@google.com <ch...@google.com> #12Nov 6, 2017 11:41AM

I tried to find the device specs and both Fujitsu arrows Be F-05J and Fujitsu arrows M04 should have 720x1280 size display. For the camera id 0 device, it is a different case that the display size is larger than 640x480 but the device only supports a 480x480 size. The case also caused the same IllegalArgumentException and was also fixed by aosp/1254406 that was merged in 2020/05/17 and should be included in 1.0.0-beta04 release. Before aosp/1254406 was merged, the only 480x480 size would be filtered out and then caused the IllegalArgumentException. After it was merged, the 640x480 size threshold was removed and then the 480x480 size would be kept and selected to use.

It looks like 1.0.0-beta04 release had been used to collect the supported sizes information. But the issue should have been fixed by 1.0.0-beta04 release. Did you only check the device model name to collect the supported sizes information or collect the information when the IllegalArgumentException issue happens again?

CameraX's 1.0.0-rc01 version has been released. There should be many fixes included in it compared to the 1.0.0-beta04 version. Maybe you can also consider to upgrade to the latest 1.0.0-rc01 version for your application. Thanks.

[Deleted User] <[Deleted User]> #13Nov 6, 2017 12:43PM

Did you only check the device model name to collect the supported sizes information or collect the information when the IllegalArgumentException issue happens again?

We collect informations only from the device on which IllegalArgumentException happened.

Our latest app uses CameraX version 1.0.0-beta10 and this issue still occurres.

However we don't receive crash report from Fujitsu arrows Be F-05J or Fujitsu arrows M04 so far. (This doesn't mean this issue is fixed on these devices because our app is heavily rely on camera so these device's user wouldn't use our app anymore.)

Instead, we receive crash report from Fujitsu F-03K.

Model : Fujitsu F-03K
Android Version : 7.1.2
Supported output sizes of ImageFormat.PRIVATE

CameraId 0 : 480x480
CameraId 1 : 2048x1536 ,1920x1080 ,1280x720 ,960x720 ,640x480 ,320x240 ,176x144

ja...@gmail.com <ja...@gmail.com> #14Nov 7, 2017 11:21PM

I missed some settings when I simulated the issue by robolectric test so that I was not able to reproduce it. Now, I can reproduce the issue if the device only supports one 480x480 resolution. I'm working on the solution and target to make it included in next release.

ch...@google.com <ch...@google.com> #15Nov 8, 2017 09:46AM

Project: platform/frameworks/support
Branch: androidx-main

commit 69d15dff7bb857ee33a0f643ff42a0f8bc475ab2
Author: charcoalchen <charcoalchen@google.com>
Date: Fri Jan 08 18:30:03 2021

Fixed IllegalArgumentException issue happened when all preview supported sizes are smaller than 640x480 and display size is larger than 640x480.

Do not filter out sizes smaller than 640x480 when all preview supported sizes are smaller than 640x480 and display size is larger than 640x480.

Relnote:"Fixed IllegalArgumentException issue happened when all preview supported sizes are smaller than 640x480 and display size is larger than 640x480."

Bug: 150506192
Test: SupportedSurfaceCombinationTest
Change-Id: I2a63ce8e2ad42a9cc060c8635ac3603bf440b1ec

M camera/camera-camera2/src/main/java/androidx/camera/camera2/internal/SupportedSurfaceCombination.java
M camera/camera-camera2/src/test/java/androidx/camera/camera2/internal/SupportedSurfaceCombinationTest.java

https://android-review.googlesource.com/1545624

[Deleted User] <[Deleted User]> #16Nov 9, 2017 07:48AM

The solution has been merged in https://android-review.googlesource.com/1545624. Update the status to be fixed.

ch...@google.com <ch...@google.com> #17Nov 9, 2017 10:00AM

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.

am...@google.com <am...@google.com> #18Nov 10, 2017 11:10AM

Marked as fixed.

The issue reported here has been fixed and it will be available in a future release.

ar...@google.com <ar...@google.com> #19Nov 13, 2017 08:59AM

This issue is fixed and released in 27.0.1 version of support library.

az...@gmail.com <az...@gmail.com> #20Nov 16, 2017 10:25AM

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> #21Nov 16, 2017 06:27PM

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]> #22Nov 17, 2017 07:54AM

This issue is not solved. It does not working properly.

jo...@gmail.com <jo...@gmail.com> #23Nov 19, 2017 03:09PM

Indeed, just tried with 27.0.1 and it's not fixed

dr...@gmail.com <dr...@gmail.com> #24Nov 23, 2017 08:58AM

27.0.1, it's not fixed.

fa...@gmail.com <fa...@gmail.com> #25Nov 23, 2017 09:05AM

27.0.1, it's not fixed， and I am using nest recyclerview

ps...@gmail.com <ps...@gmail.com> #26Nov 23, 2017 09:12AM

It's a CoordinatorLayout thing I guess. The same thing happens with items inside NestedScrollView

dr...@gmail.com <dr...@gmail.com> #27Nov 23, 2017 03:22PM

Please reopen this issue because it has not been fixed.

dr...@gmail.com <dr...@gmail.com> #28Nov 28, 2017 08:45AM

For requesting a fix, I have created a new issue:

https://issuetracker.google.com/issues/69823266

al...@google.com <al...@google.com> #29Nov 28, 2017 06:52PM

Status: Assigned (reopened)

Issue was incorrectly tagged. This has been fixed internally but is not yet available in a public release.

am...@google.com <am...@google.com> #30Nov 29, 2017 07:05AM

Marked as fixed.

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> #31Dec 3, 2017 10:45AM

Still not fixed in 27.0.2z

de...@gmail.com <de...@gmail.com> #32Dec 6, 2017 12:40PM

any progress? Still not fixed in 27.0.2

de...@gmail.com <de...@gmail.com> #33Dec 12, 2017 04:06AM

Please reopen this issue because it has not been fixed.

pr...@gmail.com <pr...@gmail.com> #34Dec 14, 2017 12:07PM

Please reopen this issue because it has not been fixed.

[Deleted User] <[Deleted User]> #35Dec 15, 2017 09:09AM

Indeed, this is still not fixed.

ay...@gmail.com <ay...@gmail.com> #36Dec 24, 2017 03:26PM

Please reopen this issue because it has not been fixed.

9g...@gmail.com <9g...@gmail.com> #37Dec 29, 2017 07:22AM

reopen this issue because it has not been fixed.!!

[Deleted User] <[Deleted User]> #38Jan 2, 2018 06:29AM

reopen this issue because it has not been fixed.!!

za...@gmail.com <za...@gmail.com> #39Jan 2, 2018 06:32AM

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> #40Jan 11, 2018 08:09AM

27.0.2 still not fixed.

ja...@gmail.com <ja...@gmail.com> #41Jan 14, 2018 08:28PM

please fix it!

de...@gmail.com <de...@gmail.com> #42Jan 14, 2018 08:38PM

Somewhere on the Internet is a workaround for this. Not cool but it works.

pe...@gmail.com <pe...@gmail.com> #43Jan 17, 2018 01:41PM

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();
}
}

pe...@gmail.com <pe...@gmail.com> #44Jan 17, 2018 01:57PM

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> #45Feb 1, 2018 02:46AM

I still have had this issue when i replaced the 27.0.2.

[Deleted User] <[Deleted User]> #46Feb 7, 2018 01:22AM

27.0.2 not fix

an...@gmail.com <an...@gmail.com> #47Feb 7, 2018 03:09AM

27.0.2 still has this issue, please fix it.

hi...@gmail.com <hi...@gmail.com> #48Feb 7, 2018 03:21AM

27.0.2 not fix too.
use

https://gist.github.com/chrisbanes/8391b5adb9ee42180893300850ed02f2 can work.
Please fix this problem, thanks !

[Deleted User] <[Deleted User]> #49Feb 13, 2018 11:35AM

27.0.2 not fix the issue.

ha...@gmail.com <ha...@gmail.com> #50Feb 15, 2018 05:10PM

Not fixed

ri...@gmail.com <ri...@gmail.com> #51Feb 17, 2018 06:16AM

Anjing

fa...@gmail.com <fa...@gmail.com> #52Feb 20, 2018 12:18PM

Are you ever gonna fix this? 5 months and still no fix

de...@gmail.com <de...@gmail.com> #53Feb 20, 2018 12:31PM

+1k!

au...@google.com <au...@google.com> #54Feb 22, 2018 06:18PM

Status: Assigned (reopened)

shepshapard@ can you take a look at this?

sh...@google.com <sh...@google.com> #55Feb 22, 2018 07:12PM

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.

za...@gmail.com <za...@gmail.com> #56Feb 22, 2018 07:51PM

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> #57Feb 28, 2018 03:23AM

Have seen Support Library update to version 27.1.0.

May I ask in this version, fix this issue?

sh...@google.com <sh...@google.com> #58Feb 28, 2018 05:55PM

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> #59Mar 5, 2018 02:35PM

The same problem while I use RecyclerView in CoordinatorLayout.

sh...@google.com <sh...@google.com> #60Mar 5, 2018 04:43PM

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.

ha...@gmail.com <ha...@gmail.com> #61Mar 23, 2018 03:47PM

How come that the problem does not occur when I select older support library version? like the 25.3.1

je...@gmail.com <je...@gmail.com> #62Apr 12, 2018 07:54AM

not fixed with version 27.1.0

https://gist.github.com/chrisbanes/8391b5adb9ee42180893300850ed02f2 works

pr...@gmail.com <pr...@gmail.com> #63Apr 23, 2018 07:52PM

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> #64May 7, 2018 06:10PM

I have a similar issue but with the BottomNavigationView, is the fix proposed applicable to Views?

sh...@google.com <sh...@google.com> #65May 7, 2018 07:27PM

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> #66Jun 5, 2018 05:17AM

27.0.2 do not fix the issue.

fa...@gmail.com <fa...@gmail.com> #67Jun 5, 2018 10:33AM

this issue is still there in 27.1.1

le...@gmail.com <le...@gmail.com> #68Jun 12, 2018 05:18PM

Also having this issue with 27.1.1

pi...@gmail.com <pi...@gmail.com> #69Jun 17, 2018 08:35AM

The same

yi...@gmail.com <yi...@gmail.com> #70Jun 21, 2018 07:31AM

same issue

de...@gmail.com <de...@gmail.com> #71Jun 21, 2018 07:51AM

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> #72Jun 21, 2018 10:09AM

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> #73Jul 5, 2018 07:31PM

Please fix it... It has been 6 months.

za...@gmail.com <za...@gmail.com> #74Jul 5, 2018 07:38PM

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> #75Jul 6, 2018 11:59AM

Also having this issue with 27.1.1

[Deleted User] <[Deleted User]> #76Jul 24, 2018 02:04PM

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> #77Aug 18, 2018 02:25AM

Just tried 28.0.0-rc01 and the problem is still there.

an...@googlemail.com <an...@googlemail.com> #78Aug 27, 2018 09:15AM

#72 if there is no reaction from any google developer to this ridiculous situation.

sh...@google.com <sh...@google.com> #79Aug 27, 2018 03:59PM

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.

fr...@gmail.com <fr...@gmail.com> #80Aug 31, 2018 11:19AM

Please give me the solution

sh...@google.com <sh...@google.com> #81Sep 4, 2018 05:43PM

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!

zz...@gmail.com <zz...@gmail.com> #82Sep 7, 2018 02:53AM

That's my solution

https://gist.github.com/AlexSmille/1168720fdb99f76d0f3e96ff4246c9ad 。

sh...@gmail.com <sh...@gmail.com> #83Sep 23, 2018 09:03AM

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 ?

sh...@gmail.com <sh...@gmail.com> #84Sep 27, 2018 06:23PM

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> #85Sep 28, 2018 07:51PM

Still an issue in 28.0.0. Are there any reliable workarounds for this issue?

lo...@gmail.com <lo...@gmail.com> #86Sep 28, 2018 08:08PM

comment#85

, yes there are. Here is mine:

https://github.com/LouisCAD/Splitties/blob/3a2e75d7342028bff21008cdf77cf68ff1efae00/viewdsl-design/src/main/java/splitties/viewdsl/design/fixedimpls/FixedAppBarLayoutBehavior.kt

am...@gmail.com <am...@gmail.com> #87Oct 9, 2018 02:26AM

I'm migrated to AndroidX and seem that this issue are fixed

am...@google.com <am...@google.com> Oct 9, 2018 06:05AM

Reassigned to ku...@google.com.

pa...@gmail.com <pa...@gmail.com> #88Oct 13, 2018 04:41PM

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?

we...@gmail.com <we...@gmail.com> #89Nov 16, 2018 09:46AM

Still seeing this issue in androidx.core 1.1.0-alpha01 with BottomNavigationView.

kp...@gmail.com <kp...@gmail.com> #90Jan 10, 2019 08:27AM

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.

sh...@google.com <sh...@google.com> #91Jan 10, 2019 06:37PM

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> #92Jan 18, 2019 08:32PM

Marked as fixed.

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!

pa...@outlook.com <pa...@outlook.com> #93Mar 14, 2019 08:17PM

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">



</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">



</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> #94Mar 14, 2019 08:51PM

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.

pa...@outlook.com <pa...@outlook.com> #95Mar 15, 2019 01:51PM

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> #96Mar 15, 2019 09:44PM

Material Design Library is actively updating this for BSB, you may track the progress here:

b/128698671

yq...@gmail.com <yq...@gmail.com> #97Mar 20, 2019 04:22AM

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> #98Nov 6, 2019 11:03AM

I'm using recycler view in bottom sheet and this issue is not fixed.
recyclerview-v7:28.0.0

vz...@gmail.com <vz...@gmail.com> #99Nov 19, 2019 10:24AM

we are using 28.0.0, the problem is still there.

sh...@google.com <sh...@google.com> #100Nov 19, 2019 10:19PM

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

sh...@google.com <sh...@google.com> #101Nov 19, 2019 10:20PM

See

comment #92

sa...@gmail.com <sa...@gmail.com> #102Dec 5, 2019 12:03AM

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]> #103Jan 24, 2020 06:30AM

I am getting same issue with androidx.recyclerview:recyclerview:1.1.0.

[Deleted User] <[Deleted User]> #104May 4, 2020 10:35AM

Bump, same issue on androix.recyclerview:recyclerview:1.1.0.

sh...@google.com <sh...@google.com> #105May 4, 2020 04:09PM

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> #106May 4, 2020 04:15PM

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> #107May 4, 2020 06:37PM

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> #108May 11, 2020 03:52AM

Also reproed while using MotionLayout :(

ma...@gmail.com <ma...@gmail.com> #109May 11, 2020 03:53AM

Also reproed while using MotionLayout :(

but it's working fine if I double tap it quickly

sh...@google.com <sh...@google.com> #110May 11, 2020 04:22PM

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> #111Nov 6, 2020 09:21AM

Updated my AndroidX dependencies and fixed the issue with appbarlayout/bottomnav/recyclerview. Did not try out MotionLayout

Issue 66996774

Description

Issue summary

Comments

am...@google.com <am...@google.com> Sep 28, 2017 03:49AM

am...@google.com <am...@google.com> #2Sep 28, 2017 10:41AM

ca...@gmail.com <ca...@gmail.com> #3Sep 29, 2017 12:58AM

ki...@gmail.com <ki...@gmail.com> #4Sep 30, 2017 07:16AM

am...@google.com <am...@google.com> #5Oct 3, 2017 09:40AM

[Deleted User] <[Deleted User]> #6Oct 4, 2017 02:50AM

lo...@gmail.com <lo...@gmail.com> #7Oct 4, 2017 02:51AM

t....@gmail.com <t....@gmail.com> #8Oct 10, 2017 03:58AM

[Deleted User] <[Deleted User]> #9Oct 21, 2017 02:18PM

ad...@gmail.com <ad...@gmail.com> #10Oct 30, 2017 12:35PM

Additional Information

[Deleted User] <[Deleted User]> #11Nov 2, 2017 07:35AM

ch...@google.com <ch...@google.com> #12Nov 6, 2017 11:41AM

[Deleted User] <[Deleted User]> #13Nov 6, 2017 12:43PM

ja...@gmail.com <ja...@gmail.com> #14Nov 7, 2017 11:21PM

ch...@google.com <ch...@google.com> #15Nov 8, 2017 09:46AM

[Deleted User] <[Deleted User]> #16Nov 9, 2017 07:48AM

ch...@google.com <ch...@google.com> #17Nov 9, 2017 10:00AM

am...@google.com <am...@google.com> #18Nov 10, 2017 11:10AM

ar...@google.com <ar...@google.com> #19Nov 13, 2017 08:59AM

az...@gmail.com <az...@gmail.com> #20Nov 16, 2017 10:25AM

dg...@gmail.com <dg...@gmail.com> #21Nov 16, 2017 06:27PM

[Deleted User] <[Deleted User]> #22Nov 17, 2017 07:54AM

jo...@gmail.com <jo...@gmail.com> #23Nov 19, 2017 03:09PM

dr...@gmail.com <dr...@gmail.com> #24Nov 23, 2017 08:58AM

fa...@gmail.com <fa...@gmail.com> #25Nov 23, 2017 09:05AM

ps...@gmail.com <ps...@gmail.com> #26Nov 23, 2017 09:12AM

dr...@gmail.com <dr...@gmail.com> #27Nov 23, 2017 03:22PM

dr...@gmail.com <dr...@gmail.com> #28Nov 28, 2017 08:45AM

al...@google.com <al...@google.com> #29Nov 28, 2017 06:52PM

am...@google.com <am...@google.com> #30Nov 29, 2017 07:05AM

ps...@gmail.com <ps...@gmail.com> #31Dec 3, 2017 10:45AM

de...@gmail.com <de...@gmail.com> #32Dec 6, 2017 12:40PM

de...@gmail.com <de...@gmail.com> #33Dec 12, 2017 04:06AM

pr...@gmail.com <pr...@gmail.com> #34Dec 14, 2017 12:07PM

[Deleted User] <[Deleted User]> #35Dec 15, 2017 09:09AM

ay...@gmail.com <ay...@gmail.com> #36Dec 24, 2017 03:26PM

9g...@gmail.com <9g...@gmail.com> #37Dec 29, 2017 07:22AM

[Deleted User] <[Deleted User]> #38Jan 2, 2018 06:29AM

za...@gmail.com <za...@gmail.com> #39Jan 2, 2018 06:32AM

sh...@gmail.com <sh...@gmail.com> #40Jan 11, 2018 08:09AM

ja...@gmail.com <ja...@gmail.com> #41Jan 14, 2018 08:28PM

de...@gmail.com <de...@gmail.com> #42Jan 14, 2018 08:38PM

pe...@gmail.com <pe...@gmail.com> #43Jan 17, 2018 01:41PM

pe...@gmail.com <pe...@gmail.com> #44Jan 17, 2018 01:57PM

hu...@gmail.com <hu...@gmail.com> #45Feb 1, 2018 02:46AM

[Deleted User] <[Deleted User]> #46Feb 7, 2018 01:22AM

an...@gmail.com <an...@gmail.com> #47Feb 7, 2018 03:09AM

hi...@gmail.com <hi...@gmail.com> #48Feb 7, 2018 03:21AM

[Deleted User] <[Deleted User]> #49Feb 13, 2018 11:35AM

ha...@gmail.com <ha...@gmail.com> #50Feb 15, 2018 05:10PM

ri...@gmail.com <ri...@gmail.com> #51Feb 17, 2018 06:16AM

fa...@gmail.com <fa...@gmail.com> #52Feb 20, 2018 12:18PM

de...@gmail.com <de...@gmail.com> #53Feb 20, 2018 12:31PM

au...@google.com <au...@google.com> #54Feb 22, 2018 06:18PM

sh...@google.com <sh...@google.com> #55Feb 22, 2018 07:12PM

za...@gmail.com <za...@gmail.com> #56Feb 22, 2018 07:51PM

dr...@gmail.com <dr...@gmail.com> #57Feb 28, 2018 03:23AM

sh...@google.com <sh...@google.com> #58Feb 28, 2018 05:55PM

sp...@gmail.com <sp...@gmail.com> #59Mar 5, 2018 02:35PM

sh...@google.com <sh...@google.com> #60Mar 5, 2018 04:43PM

ha...@gmail.com <ha...@gmail.com> #61Mar 23, 2018 03:47PM

je...@gmail.com <je...@gmail.com> #62Apr 12, 2018 07:54AM

pr...@gmail.com <pr...@gmail.com> #63Apr 23, 2018 07:52PM

su...@gmail.com <su...@gmail.com> #64May 7, 2018 06:10PM

sh...@google.com <sh...@google.com> #65May 7, 2018 07:27PM

ny...@gmail.com <ny...@gmail.com> #66Jun 5, 2018 05:17AM

fa...@gmail.com <fa...@gmail.com> #67Jun 5, 2018 10:33AM

le...@gmail.com <le...@gmail.com> #68Jun 12, 2018 05:18PM

pi...@gmail.com <pi...@gmail.com> #69Jun 17, 2018 08:35AM

yi...@gmail.com <yi...@gmail.com> #70Jun 21, 2018 07:31AM

de...@gmail.com <de...@gmail.com> #71Jun 21, 2018 07:51AM

t....@gmail.com <t....@gmail.com> #72Jun 21, 2018 10:09AM

cn...@gmail.com <cn...@gmail.com> #73Jul 5, 2018 07:31PM

za...@gmail.com <za...@gmail.com> #74Jul 5, 2018 07:38PM

da...@gmail.com <da...@gmail.com> #75Jul 6, 2018 11:59AM