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

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

commit 2db6d01af84b5752190c6dd28cdea12500b701cb
Author: Charcoal Chen <charcoalchen@google.com>
Date: Fri Dec 23 10:15:10 2022

Fix JPEG image corruption issue if writing Exif location data on some Samsung Android 12 devices

This issue can be avoided in CameraX side by skipping the unnecessary Exif data copy. But there should still be some unknown reason in ExifInterface or these problematic devices to cause the issue.

b/263747161

has been reported to ExifInterface owner to do further clarification for this issue.

Relnote: "Fixed JPEG image corruption issue if writing Exif location data on some Samsung Android 12 devices."

Bug: 263289024
Test: ImageCaptureTest

Change-Id: Ib70862aa6e654f06b9358e3f92bbb98c86cb9caf

M camera/camera-core/src/main/java/androidx/camera/core/impl/utils/Exif.java
M camera/integration-tests/coretestapp/src/androidTest/java/androidx/camera/integration/core/ImageCaptureTest.kt

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

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

Thanks for reporting, i can use the example app to reproduce the problem. I saved the corrupted file and pulled it off the device and ran it through exiftool, which complained (it doesn't complain as loudly about the source file, just some technically out-of-order tags):

$ exiftool -v2 editedFile.jpg
  ExifToolVersion = 12.52
  FileName = editedFile.jpg
  Directory = .
  FileSize = 433785
  FileModifyDate = 1678109782
  FileAccessDate = 1678109782
  FileInodeChangeDate = 1678109782
  FilePermissions = 33184
  FileType = JPEG
  FileTypeExtension = JPG
  MIMEType = image/jpeg
  Warning = [minor] Skipped unknown 617 bytes after JPEG APP1 segment
JPEG APP1 (46 bytes):
  ExifByteOrder = II
  Warning = Short directory size for IFD0 (missing 150 bytes)
  | Warning = Bad IFD0 directory
  Warning = [minor] Skipped unknown 917 bytes after JPEG NULL segment
JPEG SOI
JPEG APP0 (14 bytes):
  + [BinaryData directory, 9 bytes]
  | JFIFVersion = 1 1
  | - Tag 0x0000 (2 bytes, int8u[2])
  | ResolutionUnit = 0
  | - Tag 0x0002 (1 bytes, int8u[1])
  | XResolution = 1
  | - Tag 0x0003 (2 bytes, int16u[1])
  | YResolution = 1
  | - Tag 0x0005 (2 bytes, int16u[1])
  | ThumbnailWidth = 0
  | - Tag 0x0007 (1 bytes, int8u[1])
  | ThumbnailHeight = 0
  | - Tag 0x0008 (1 bytes, int8u[1])
JPEG DQT (65 bytes):
JPEG DQT (65 bytes):
JPEG SOF0 (15 bytes):
  ImageWidth = 512
  ImageHeight = 384
  EncodingProcess = 0
  BitsPerSample = 8
  ColorComponents = 3
  YCbCrSubSampling = 2 1
JPEG DHT (29 bytes):
JPEG DHT (179 bytes):
JPEG DHT (29 bytes):
JPEG DHT (179 bytes):
JPEG SOS

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

The size of the JPEG APP1 segment looks wrong in the edited file (from exiftool):

JPEG APP1 (46 bytes):

Compared to the original file:

JPEG APP1 (65279 bytes):

In binary this difference is visible in the 5th/6th byte of each file (from hexdump -C). The first 4 bytes are a JPEG marker (0xFF), a JPEG SOI (start of image, 0xd8), another marker and an APP1 (0xe1), followed by 2 bytes indicating the size of the APP1 segment.

Edited image:

ff d8 ff e1 00 30

Original image:

ff d8 ff e1 ff 01

Looking into why ExifInterface is writing out the wrong APP1 size, I turned on debug logging:

$ adb shell setprop log.tag.ExifInterface VERBOSE

And now it becomes a bit more obvious (this logging is from here and here):

saveJpegAttributes starting with (inputStream: java.io.BufferedInputStream@4fba9e8, outputStream: java.io.BufferedOutputStream@e5c3801)
index: 0, offsets: 8, tag count: 15, data sizes: 81, total size: 65584

65584 (0x10030) is greater than the max 16-bit unsigned value (2^16 = 65536), so when we pass it to ByteOrderedDataOutputStream.writeUnsignedShort, the naive cast (writeShort((short) val)) truncates to the lower two bytes (0x0030) - and this gets written out to the file and then breaks everything.

I think this likely only affects files that are very close to the 2^16 threshold, and the act of 'copying' all the EXIF attributes over probably reformats some of them just enough to take up slightly more bytes.

I'm not sure what is supposed to happen when a JPEG APP1 segment gets larger than 2^16 bytes, I need to dig a bit further into that part.

TestApplication.zip

34 MB

Download

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

Actually thinking about it more, it's not obvious to me why the APP1 segment of the original image is so large either - looking in exiftool it doesn't seem to contain any particularly enormous fields, so I can't really see where 65kB comes from.

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

re comment #5 about why the original APP1 segment is so large, I missed the thumbnail the first time, which takes up a significant chunk (64kB):

  + [IFD1 directory with 15 entries]
  | 0)  ImageHeight = 384
  |     - Tag 0x0101 (4 bytes, int32u[1]):
  |         0323: 80 01 00 00                                     [....]
  | 1)  Orientation = 6
  |     - Tag 0x0112 (2 bytes, int16u[1]):
  |         032f: 06 00                                           [..]
  | Warning = Tag ID 0x0103 Compression out of sequence in IFD1
  | 2)  Compression = 6
  |     - Tag 0x0103 (2 bytes, int16u[1]):
  |         033b: 06 00                                           [..]
  | 3)  ThumbnailOffset = 1273
  |     - Tag 0x0201 (4 bytes, int32u[1]):
  |         0347: f9 04 00 00                                     [....]
  | 4)  ThumbnailLength = 64000
  |     - Tag 0x0202 (4 bytes, int32u[1]):
  |         0353: 00 fa 00 00                                     [....]
  | Warning = Tag ID 0x010f Make out of sequence in IFD1

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

Wikipedia reckons we can't put Exif anywhere except APP1:

Exif metadata are restricted in size to 64 kB in JPEG images because according to the specification this information must be contained within a single JPEG APP1 segment.

Charcoal: Do you know if CameraX is deciding how large to make the thumbnail in this case, or is this happening lower down in the device? Taking up 64,000 bytes doesn't leave much space for the rest of the Exif data.

Related thread I found (also complaining about a Samsung device, but from 2013...): https://exiftool.org/forum/index.php?topic=5103.0

I experimented to see what exiftool does now when the APP1 segment gets too large, and it looks like they just add a second APP1 segment and call it 'multi-segment EXIF` (I have no idea how well supported this is):

$ exiftool -UserComment="abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz" b-263747161_original.jpg
Warning: [minor] File contains multi-segment EXIF - b-263747161_original.jpg
    1 image files updated

$ exiftool -v3 b-263747161_original.jpg
  ExifToolVersion = 12.52
  FileName = b-263747161_original.jpg
  Directory = .
  FileSize = 434075
  FileModifyDate = 1678121141
  FileAccessDate = 1678121141
  FileInodeChangeDate = 1678121141
  FilePermissions = 33184
  FileType = JPEG
  FileTypeExtension = JPG
  MIMEType = image/jpeg
JPEG APP1 (65533 bytes):
    0006: 45 78 69 66 00 00 49 49 2a 00 08 00 00 00 0d 00 [Exif..II*.......]
    0016: 00 01 04 00 01 00 00 00 a0 05 00 00 01 01 04 00 [................]
    0026: 01 00 00 00 38 04 00 00 0e 01 02 00 01 00 00 00 [....8...........]
    0036: 00 00 00 00 0f 01 02 00 08 00 00 00 aa 00 00 00 [................]
    0046: 10 01 02 00 09 00 00 00 b2 00 00 00 12 01 03 00 [................]
    0056: 01 00 00 00 06 00 00 00 1a 01 05 00 01 00 00 00 [................]
    0066: bc 00 00 00 1b 01 05 00 01 00 00 00 c4 00 00 00 [................]
    [snip 65421 bytes]
  Warning = [minor] File contains multi-segment EXIF
JPEG APP1 (71 bytes):
   10007: 45 78 69 66 00 00 00 00 00 00 00 00 00 00 00 00 [Exif............]
   10017: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [................]
   10027: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [................]
   10037: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [................]
   10047: 00 00 00 00 00 00 00                            [.......]
  ExifByteOrder = II

Obviously the current ExifInterface behaviour is very problematic (corrupting the image completely), but I'm not actually sure the best way to improve it. Some options I came up with:

If the size of the APP1 segment is larger than 2^16 then just write the first 2^16 bytes and hope.
Implement the same 'split segment' support that exiftool has.
Add logic to ExifInterface to resize a thumbnail to free up space in the APP1 segment if it runs out (this seems too magical and could be very confusing for users).
Refuse to save a file in ExifInterface.saveAttributes if it results in APP1 being larger than 2^16, either by silently not writing out (confusing) or throwing an exception (disruptive).
Add prioritisation of Exif tags, so when we run out of space we drop tags lowest-priority-first (very unlikely we can predict the 'correct' prioritisation such that users aren't annoyed/confused by the tags we decide to drop).

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

Hi Ian,

Thanks for looking into the issue and provide the detailed analysis result.

About the question: Charcoal: Do you know if CameraX is deciding how large to make the thumbnail in this case, or is this happening lower down in the device? Taking up 64,000 bytes doesn't leave much space for the rest of the Exif data.

CameraX doesn't specify any thumbnail related capture request settings (CaptureRequest#JPEG_THUMBNAIL_SIZE, CaptureRequest#JPEG_THUMBNAIL_QUALITY) when capturing the image. It depends on OEM's implementation to decide what the default thumbnail size and quality should be.

I'm curious about why this issue only happens when setting a FUSED location data but does not happen when setting a GPS location data? Does the FUSED location data in Exif actually occupy a little bit more size than GPS location data? So it causes the different result?

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

I'm curious about why this issue only happens when setting a FUSED location data but does not happen when setting a GPS location data? Does the FUSED location data in Exif actually occupy a little bit more size than GPS location data? So it causes the different result?

Good question - I actually only got as far as playing with the image provided inside MyApplication-ExifLocationIssue.zip, I didn't look at CameraXBasic-WriteFusedLocation.zip, and as you noted in comment #1 both location providers cause a problem in the non-CameraX example app. My guess would be as you say, the Exif data ends up a tiny bit larger and causes the problem. If I have time I can dig in and show that more conclusively.

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

I've decided to go with option 4 from comment #7 and throw an exception from saveAttributes in order to avoid creating a corrupted image. I've filed a new issue to track the possibility of adding multi-segment support in the future: https://issuetracker.google.com/271999370

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

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

commit c6bbc03f39f811ac546882880be46380cb31f5d5
Author: Ian Baker <ibaker@google.com>
Date: Tue Mar 07 11:09:08 2023

Throw an exception if trying to write a JPEG APP1 segment that's too large

jpeg_with_full_app_segment.jpg is an image taken with a Samsung A32
with a nearly-full APP1 segment due to a 64,000 byte thumbnail:

$ exiftool -v3 jpeg_with_exif_full_app1_segment.jpg
<snip>
JPEG APP1 (65072 bytes):
<snip>
| 5) ThumbnailLength = 64000

Bug: 263747161
Test: ./gradlew :exifinterface:exifinterface:connectedAndroidTest

Change-Id: Id421cd36d974ad4f29a2c6d6c730d99d8986d917

M exifinterface/exifinterface/build.gradle
M exifinterface/exifinterface/src/androidTest/java/androidx/exifinterface/media/ExifInterfaceTest.java
A exifinterface/exifinterface/src/androidTest/res/raw/jpeg_with_exif_full_app1_segment.jpg
M exifinterface/exifinterface/src/main/java/androidx/exifinterface/media/ExifInterface.java

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

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

Are you sure it's an issue with the APP1 segment being too large with the FUSED location? I was thinking perhaps there's some issue with the length calculation that's happening as we were able to fix these images by just detecting the start of the jpeg image data and re-writing the length field based on that detection.

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

Are you sure it's an issue with the APP1 segment being too large with the FUSED location? I was thinking perhaps there's some issue with the length calculation that's happening as we were able to fix these images by just detecting the start of the jpeg image data and re-writing the length field based on that detection.

This fix is consistent with the current failure mode of ExifInterface when the APP1 segment gets 'too large' (before my change linked above in comment #11). The image ends up 'corrupt' because we have 0x10030 bytes to write to the APP1 segment, and ExifInterface does two things:

When writing the length of the APP1 segment it truncates this to 0x0030
It writes all those 0x10030 bytes out, and then it writes the rest of the image.

A JPEG parser (I assume) comes along and reads the length of the APP1 segment (0x30) and skips that many bytes, then expects to find JPEG data - but it's actually in the middle of the Exif and so it fails.

If you manually find the start of the JPEG data then you obviate both of the problems - and the image is 'fixed'.

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

The following release(s) address this bug.It is possible this bug has only been partially addressed:

androidx.exifinterface:exifinterface:1.3.7

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

The following release(s) address this bug.It is possible this bug has only been partially addressed:

androidx.exifinterface:exifinterface:1.4.0-alpha01

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

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

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

[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

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