[ViewPager2] SwipeRefreshLayout misbehaves when used with ViewPage2 [136269311]

Duplicate

of 131115697

Bug

Status Update

No update yet.

Description

be...@gmail.com

created issue #1

Jun 29, 2019 05:04PM

When SwipeRefreshLayout resides inside a FragmentPage of ViewPage2 and swipe-down gesture starts, ViewPage2's left-right gesture is not ignored but overrules swipe-down gesture of SwipeRefreshLayout instead, breaking SwipeRefreshLayout's behavior (see screencast

https://streamable.com/40bl2)

Steps to reproduce:
* Start swipe-down gesture
* Continue gesture until SwipeRefreshLayout's loading indicator becomes (partly) visible
* Move finger to the left or to the right

Actual behavior
* Swipe-down gesture gets cancelled
* SwipeRefreshLayout's loading indicator freezes
* ViewPage2's left-right swiping gesture starts

Expected behavior
* Swipe-down gesture gets continued
* SwipeRefreshLayout's loading indicator doesn't freeze
* ViewPage2's left-right swiping gesture gets ignored

Reproduces with "androidx.viewpager2:viewpager2:1.0.0-alpha05"

Comments

jg...@google.com <jg...@google.com> #2Jul 1, 2019 04:36PM

Assigned to je...@google.com.

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

commit c2365dcfeb9064814282304f30f3eb86be71fdc7
Author: Dan Nizri <dniz@google.com>
Date: Wed Dec 20 16:33:08 2023

Fix Popup back handling on Android T/13+ when android:enableOnBackInvokedCallback="true"

Bug: 313702338
Bug: 318537200
Test: tested with android:enableOnBackInvokedCallback="true"
Change-Id: I7c7cef686ed9fbfd2d144c90040b13528f1675ed

M compose/ui/ui/src/androidMain/kotlin/androidx/compose/ui/window/AndroidPopup.android.kt

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

be...@gmail.com <be...@gmail.com> #3Jul 1, 2019 04:47PM

Is there remaining work for this feature request. Support for predictive back in Dialogs would allow Material3 to remove some Dialog forks and would be very helpful!

je...@google.com <je...@google.com> Jul 1, 2019 05:00PM

Status: Duplicate of

131115697

je...@google.com <je...@google.com> #4Jul 2, 2019 09:33AM

Yeah, we probably want to investigate new API shapes here to take advantage of predictive back. No work ongoing yet though, needs prioritization

be...@gmail.com <be...@gmail.com> #5Jul 2, 2019 09:36AM

Pinging here, as we're facing a similar issue on Wear OS, PB support on Dialogs would allow us to simplify/remove some components that handle swipe to dismiss behaviour and consolidate the back gesture throughout the system.

be...@gmail.com <be...@gmail.com> #6Sep 18, 2019 07:29AM

(recapping my chat with Ian)

The tricky part is that the onDismissRequest is really the final signal and a chance for the app to just say 'nope, I don't want the dialog to dismiss' (since they own the state of 'should the dialog be shown or not' simply by either adding the Dialog to composition or leaving out of composition) - that's the just-in-time problem that the comment talks about. It would be very odd to have any kind of progress animation that doesn't actually lead to the dialog being dismissed when it is committed"

so really it needs to be a more holistic look at how to do dialogs and swap from a binary state (shown/not shown) to something that actually has something in between for cases like predictive back

je...@google.com <je...@google.com> #7Sep 18, 2019 09:04AM

Ah yes, that is another known issue in SwipeRefreshLayout.
That bug is tracked here:

https://issuetracker.google.com/138314213
Until we get the fix in, you can work around that issue by following

comment #20

(

http://issuetracker.google.com/138314213#comment20)

be...@gmail.com <be...@gmail.com> #8Sep 18, 2019 09:40AM

Good to know the bug is tracker and is going to the fixed! Thanks a lot!