Status Update
Comments
po...@google.com <po...@google.com>
ma...@google.com <ma...@google.com> #2
Over to Ralston to take a look. I imagine with the new relocation logic it should be fixed?
je...@gmail.com <je...@gmail.com> #3
What is happening here is that the TextField does not know that it is in a scrollable container, and since the keyboard is going to hide the currently focused text, the text field calls View.requestRectangleOnScreen which causes the entire app to pan up, and that clips the top bar.
The Relocation APIs are experimental right now. It is not used in TextField as we are past the alpha stage and can only use stable APIs in TextField. So this bug can only be fixed post 1.0
ma...@google.com <ma...@google.com> #4
This should be fixed by
I verified that this sample code now works when soft input mode is AdjustResize.
je...@gmail.com <je...@gmail.com> #5
I just tested Compose 1.2.0-alpha02 and mouse scrolling on ChromeOS is still broken...
Attached is an updated sample app suing 1.2.0-alpha02 (from original posting)
ma...@google.com <ma...@google.com> #6
Thanks for the sample. It is simple indeed and I think it should work, just checked on the android (12 and 11), both mouse and trackpad work fine.
Is there an issue in the arc++ that needs investigation?
Travis, could you please triage for someone to take a look in your team?
tg...@google.com <tg...@google.com> #7
Confirmed with my own test app that external mouse scrolling is still not working with 1.2.0.apha02.
tg...@google.com <tg...@google.com> #8
Adding some debug logs from my testing on Chrome OS device that shows difference between Motion events received from trackpad vs. mouse wheel scrolling. Still not sure what the root cause of the issue is, but malkov@ let me know if anything jumps out to you.
Trackpad:
2022-01-28 15:09:40.426 13621-13621/androidx.compose.material.catalog D/ArcInputCompatHandler: Scrolling Gesture started at (586.28125, 415.91016) will apply compatibility=(mUseMouseScrollCompat=false, mUseMouseTouchScreenEmulation=false)
2022-01-28 15:09:40.428 13621-13621/androidx.compose.material.catalog I/tgorkin: PointerInputEventProcessor::process MotionEvent { action=ACTION_DOWN, actionButton=0, id[0]=0, x[0]=586.28125, y[0]=415.91016, toolType[0]=TOOL_TYPE_FINGER, buttonState=0, metaState=META_NUM_LOCK_ON, flags=0x0, edgeFlags=0x0, pointerCount=1, historySize=0, eventTime=94163014, downTime=94163014, deviceId=0, source=0x2002 }
2022-01-28 15:09:40.445 13621-13621/androidx.compose.material.catalog I/tgorkin: PointerInputEventProcessor::process MotionEvent { action=ACTION_MOVE, actionButton=0, id[0]=0, x[0]=586.28125, y[0]=381.9829, toolType[0]=TOOL_TYPE_FINGER, buttonState=0, metaState=META_NUM_LOCK_ON, flags=0x0, edgeFlags=0x0, pointerCount=1, historySize=2, eventTime=94163024, downTime=94163014, deviceId=0, source=0x2002 }
...
2022-01-28 15:09:40.580 13621-13621/androidx.compose.material.catalog I/tgorkin: PointerInputEventProcessor::process MotionEvent { action=ACTION_MOVE, actionButton=0, id[0]=0, x[0]=586.28125, y[0]=240.16827, toolType[0]=TOOL_TYPE_FINGER, buttonState=0, metaState=META_NUM_LOCK_ON, flags=0x0, edgeFlags=0x0, pointerCount=1, historySize=2, eventTime=94163174, downTime=94163014, deviceId=0, source=0x2002 }
2022-01-28 15:09:40.660 13621-13621/androidx.compose.material.catalog D/ArcInputCompatHandler: Scrolling Gesture stopped at (586.28125, 240.16827) with delta=(0.0, -175.74188) has applied compatibility=(mUseMouseScrollCompat=false, mUseMouseTouchScreenEmulation=false)
2022-01-28 15:09:40.661 13621-13621/androidx.compose.material.catalog I/tgorkin: PointerInputEventProcessor::process MotionEvent { action=ACTION_UP, actionButton=0, id[0]=0, x[0]=586.28125, y[0]=240.16827, toolType[0]=TOOL_TYPE_FINGER, buttonState=0, metaState=META_NUM_LOCK_ON, flags=0x0, edgeFlags=0x0, pointerCount=1, historySize=0, eventTime=94163172, downTime=94163014, deviceId=0, source=0x2002 }
Mouse wheel:
2022-01-28 15:12:10.282 13621-13621/androidx.compose.material.catalog I/tgorkin: PointerInputEventProcessor::process MotionEvent { action=ACTION_SCROLL, actionButton=0, id[0]=0, x[0]=1345.1406, y[0]=353.08594, toolType[0]=TOOL_TYPE_MOUSE, buttonState=0, metaState=META_NUM_LOCK_ON, flags=0x0, edgeFlags=0x0, pointerCount=1, historySize=0, eventTime=94312882, downTime=94163014, deviceId=0, source=0x2002 }
2022-01-28 15:12:11.537 13621-13621/androidx.compose.material.catalog I/tgorkin: PointerInputEventProcessor::process MotionEvent { action=ACTION_SCROLL, actionButton=0, id[0]=0, x[0]=1345.1406, y[0]=353.08594, toolType[0]=TOOL_TYPE_MOUSE, buttonState=0, metaState=META_NUM_LOCK_ON, flags=0x0, edgeFlags=0x0, pointerCount=1, historySize=0, eventTime=94314136, downTime=94163014, deviceId=0, source=0x2002 }
2022-01-28 15:12:11.852 13621-13621/androidx.compose.material.catalog I/tgorkin: PointerInputEventProcessor::process MotionEvent { action=ACTION_SCROLL, actionButton=0, id[0]=0, x[0]=1345.1406, y[0]=353.08594, toolType[0]=TOOL_TYPE_MOUSE, buttonState=0, metaState=META_NUM_LOCK_ON, flags=0x0, edgeFlags=0x0, pointerCount=1, historySize=0, eventTime=94314451, downTime=94163014, deviceId=0, source=0x2002 }
2022-01-28 15:12:12.022 13621-13621/androidx.compose.material.catalog I/tgorkin: PointerInputEventProcessor::process MotionEvent { action=ACTION_SCROLL, actionButton=0, id[0]=0, x[0]=1345.1406, y[0]=353.08594, toolType[0]=TOOL_TYPE_MOUSE, buttonState=0, metaState=META_NUM_LOCK_ON, flags=0x0, edgeFlags=0x0, pointerCount=1, historySize=0, eventTime=94314620, downTime=94163014, deviceId=0, source=0x2002 }
ma...@google.com <ma...@google.com>
ma...@google.com <ma...@google.com> #9
Given the info I know about ARC++, the difference between logs is correct, because in ARC++ layers the trackpad events from the driver are translated to "touch down + touch move" events.
For mouse, on the other hand, there are separate set of events that android views and compose should be able to handle. I can try to log some events on the android side and detect the difference.
Tried again the simple demo with the LazyColumn on android device- mouse scrolling works as expected. below are the similar logs for PointerInputEventProcessor
process: MotionEvent { action=ACTION_SCROLL, actionButton=0, id[0]=0, x[0]=436.61588, y[0]=656.72345, toolType[0]=TOOL_TYPE_MOUSE, buttonState=0, classification=NONE, metaState=META_NUM_LOCK_ON, flags=0x0, edgeFlags=0x0, pointerCount=1, historySize=0, eventTime=128779771, downTime=0, deviceId=8, source=0x2002, displayId=0, eventId=32743201 }
process: MotionEvent { action=ACTION_SCROLL, actionButton=0, id[0]=0, x[0]=436.61588, y[0]=656.72345, toolType[0]=TOOL_TYPE_MOUSE, buttonState=0, classification=NONE, metaState=META_NUM_LOCK_ON, flags=0x0, edgeFlags=0x0, pointerCount=1, historySize=0, eventTime=128779861, downTime=0, deviceId=8, source=0x2002, displayId=0, eventId=903314162 }
process: MotionEvent { action=ACTION_SCROLL, actionButton=0, id[0]=0, x[0]=436.61588, y[0]=656.72345, toolType[0]=TOOL_TYPE_MOUSE, buttonState=0, classification=NONE, metaState=META_NUM_LOCK_ON, flags=0x0, edgeFlags=0x0, pointerCount=1, historySize=0, eventTime=128779923, downTime=0, deviceId=8, source=0x2002, displayId=0, eventId=258714199 }
process: MotionEvent { action=ACTION_SCROLL, actionButton=0, id[0]=0, x[0]=436.61588, y[0]=656.72345, toolType[0]=TOOL_TYPE_MOUSE, buttonState=0, classification=NONE, metaState=META_NUM_LOCK_ON, flags=0x0, edgeFlags=0x0, pointerCount=1, historySize=0, eventTime=128779995, downTime=0, deviceId=8, source=0x2002, displayId=0, eventId=755011596 }
process: MotionEvent { action=ACTION_SCROLL, actionButton=0, id[0]=0, x[0]=436.61588, y[0]=656.72345, toolType[0]=TOOL_TYPE_MOUSE, buttonState=0, classification=NONE, metaState=META_NUM_LOCK_ON, flags=0x0, edgeFlags=0x0, pointerCount=1, historySize=0, eventTime=128780042, downTime=0, deviceId=8, source=0x2002, displayId=0, eventId=649551857 }
process: MotionEvent { action=ACTION_SCROLL, actionButton=0, id[0]=0, x[0]=436.61588, y[0]=656.72345, toolType[0]=TOOL_TYPE_MOUSE, buttonState=0, classification=NONE, metaState=META_NUM_LOCK_ON, flags=0x0, edgeFlags=0x0, pointerCount=1, historySize=0, eventTime=128780108, downTime=0, deviceId=8, source=0x2002, displayId=0, eventId=445122733 }
Seems like the only noticeable difference is the downTime
being non-zero for chromeos, but this shouldn't affect anything as we ignore the down pointers when scrolling.
While I unfortunately don't have time right now to access the proper chromeos setup, the next I can suggest would be:
- Try to find a ACTION_SCROLL specific code in ARC++, if exists.
- Try to log
motionEvent.getAxisValue(MotionEvent.AXIS_VSCROLL)
andmotionEvent.getAxisValue(MotionEvent.AXIS_HSCROLL)
to see if there is actually any scroll delta in the MotionEvent from chromeos.
Gina, over to you while Travis is OOO
gd...@google.com <gd...@google.com> #10
I think Travis and Patrick are both correct in their assessment of scrolling working/not working. It seems that scrolling will work on a Chromebook after a user moves their mouse (which seems to trigger some sort of "reset" state). However, if I finish scrolling and then try to scroll again, it often times doesn't work.
Here's some sample logcat output for a use case where the scroll didn't actually scroll the screen. It looks like it's detecting the gesture but the gesture isn't actually scrolling:
03-03 15:32:49.159 416 490 D system_server: Start Scrolling Gesture at (2077.904785, 1058.383667)
03-03 15:32:49.159 416 490 D system_server: Stop Scrolling Gesture at (2077.904785, 1058.383667) with delta=(0.000000, 0.000000)
03-03 15:32:49.159 416 490 D system_server: Stop Scrolling Gesture at (2077.904785, 1058.383667) with delta=(0.000000, 0.000000)
03-03 15:32:49.160 416 490 D system_server: Start Scrolling Gesture at (2077.904785, 1058.383667)
03-03 15:32:49.162 4396 4396 D ArcInputEventCompatProcessor: Scrolling Gesture started at (2077.9048, 1058.3837) will apply compatibility=(mUseMouseScrollCompat=false, mUseMouseTouchScreenEmulation=false)
03-03 15:32:49.169 4396 4396 D ArcInputEventCompatProcessor: Scrolling Gesture started at (2077.9048, 1058.3837) will apply compatibility=(mUseMouseScrollCompat=false, mUseMouseTouchScreenEmulation=false)
03-03 15:32:49.845 416 490 D system_server: Stop Scrolling Gesture at (2077.904785, 1462.345337) with delta=(-403.961670, 0.000000)
03-03 15:32:49.845 416 490 D system_server: Stop Scrolling Gesture at (2077.904785, 1462.345337) with delta=(-403.961670, 0.000000)
03-03 15:32:49.847 4396 4396 D ArcInputEventCompatProcessor: Scrolling Gesture stopped at (2077.9048, 1462.3453) with delta=(0.0, 403.96167) has applied compatibility=(mUseMouseScrollCompat=false, mUseMouseTouchScreenEmulation=false)
Here's logs from after a scroll after a mouse movement (which scrolled successfully):
03-03 15:36:18.479 416 490 D system_server: Start Scrolling Gesture at (1989.447632, 1224.196167)
03-03 15:36:18.481 4396 4396 D ArcInputEventCompatProcessor: Scrolling Gesture started at (1989.4476, 1224.1962) will apply compatibility=(mUseMouseScrollCompat=false, mUseMouseTouchScreenEmulation=false)
03-03 15:36:19.818 416 490 D system_server: Stop Scrolling Gesture at (2015.782593, 943.728271) with delta=(280.467896, -26.334961)
03-03 15:36:19.819 416 490 D system_server: Stop Scrolling Gesture at (2015.782593, 943.728271) with delta=(280.467896, -26.334961)
03-03 15:36:19.821 4396 4396 D ArcInputEventCompatProcessor: Scrolling Gesture stopped at (2015.7826, 943.7283) with delta=(26.33496, -280.4679) has applied compatibility=(mUseMouseScrollCompat=false, mUseMouseTouchScreenEmulation=false)
03-03 15:36:20.022 416 490 D system_server: Start Scrolling Gesture at (1989.447632, 1224.196167)
03-03 15:36:20.022 416 490 D system_server: Stop Scrolling Gesture at (1989.447632, 1224.196167) with delta=(0.000000, 0.000000)
03-03 15:36:20.022 416 490 D system_server: Stop Scrolling Gesture at (1989.447632, 1224.196167) with delta=(0.000000, 0.000000)
03-03 15:36:20.024 4396 4396 D ArcInputEventCompatProcessor: Scrolling Gesture started at (1989.4476, 1224.1962) will apply compatibility=(mUseMouseScrollCompat=false, mUseMouseTouchScreenEmulation=false)
I lifted my finger and it didn't log a "Scrolling Gesture stopped" event from ArcInputEventCompatProcessor. Could this potentially be the issue? I'll continue to dive deeper to determine the root cause.
Below is the scroll events for an app that doesn't use Compose (Among Us app)
03-03 16:54:07.960 416 490 D system_server: Start Scrolling Gesture at (2594.929688, 1266.257812)
03-03 16:54:07.960 416 490 D system_server: Stop Scrolling Gesture at (2594.929688, 1266.257812) with delta=(0.000000, 0.000000)
03-03 16:54:07.960 416 490 D system_server: Stop Scrolling Gesture at (2594.929688, 1266.257812) with delta=(0.000000, 0.000000)
03-03 16:54:07.963 4668 4668 D ArcInputEventCompatProcessor: Scrolling Gesture started at (2594.9297, 1266.2578) will apply compatibility=(mUseMouseScrollCompat=false, mUseMouseTouchScreenEmulation=true)
03-03 16:54:07.969 416 490 D system_server: Start Scrolling Gesture at (2594.929688, 1266.257812)
03-03 16:54:07.971 4668 4668 D ArcInputEventCompatProcessor: Scrolling Gesture started at (2594.9297, 1266.2578) will apply compatibility=(mUseMouseScrollCompat=false, mUseMouseTouchScreenEmulation=true)
03-03 16:54:10.968 416 490 D system_server: Stop Scrolling Gesture at (2608.095703, 1378.199585) with delta=(-111.941772, -13.166016)
03-03 16:54:10.968 416 490 D system_server: Stop Scrolling Gesture at (2608.095703, 1378.199585) with delta=(-111.941772, -13.166016)
03-03 16:54:10.969 4668 4668 D ArcInputEventCompatProcessor: Scrolling Gesture stopped at (2608.0957, 1378.1996) with delta=(13.166016, 111.94177) has applied compatibility=(mUseMouseScrollCompat=false, mUseMouseTouchScreenEmulation=true)
gd...@google.com <gd...@google.com> #11
I pulled the top of tree for Android and re-tested this with additional logging. I can't reproduce this use case of a missing scrolling gesture in the framework. I confirmed the logs are nearly identical between the logs of the working recycler view (create without Compose) and the Compose equivalent. This makes me think that Compose and the legacy recycler view are receiving the same events from the framework, but they're being handled differently by Compose.
@Matvei, I'm happy to help look into this on the Compose side, but would you be able to give me a few suggestions of where to start the investigation within the Compose framework? I'll assign to you for direction of where to investigate, but feel free to assign back to me once I've gotten this additional context. Thanks!
sa...@google.com <sa...@google.com>
jb...@google.com <jb...@google.com> #12
gd...@google.com <gd...@google.com>
gd...@google.com <gd...@google.com> #13
@jeffdcamp @samgportilla when reproducing this bug using the latest Compose release, this issue is only reproducible when using the trackpad of the Chromebook, NOT when using the wheel built into a physical mouse. Additionally, it seems that the failed scroll always comes after a successful scroll attempt. Can you both confirm whether this is the experience you've been seeing as well? Thank you!
Additionally, pasting the info of further findings here for stakeholder visibility. This info was originally shared via email with members of the Compose team:
I've been digging into the code more and comparing the code path when a scroll works and when it doesn't. It seems that the code paths diverge because the
It seems the difference between the successful and failed scroll attempts seems to lie within something regarding the pointerHandlers.
The pointerHandlers object is empty for scroll attempts that fail, yet has a size of 1 for scrolls that succeed. I've attached a sample stack trace for adding the single object to pointerHandler in a successful scroll (PointerHandlersAdd_SuccessfulScrollExample.txt).
In the scrolls that fail, I've seen instances where either the single object in the pointerHandlers is never added, or the object is removed. I've attached a sample stack trace of the removal in a failed scroll as well (PointerHandlersRemove_ScrollFailExample.txt).
I've also attached the log output for a successful vs. failed scroll. For internal stakeholders, this is a link to
Firstly, the logs first divide when the successful scroll
03-28 14:54:24.939 18081 18081 I SuspendingPointerInputFilter.kt: NEW GINA GINA GINA adding handlerCoroutine to pointerHandlers
03-28 14:54:24.939 18081 18081 I SuspendingPointerInputFilter.kt: NEW GINA GINA GINA removing this from pointerHandlers
03-28 14:54:24.939 18081 18081 I SuspendingPointerInputFilter.kt: NEW GINA GINA GINA adding handlerCoroutine to pointerHandlers
03-28 14:54:24.939 18081 18081 I Draggable.kt: NEW GINA GINA GINA in awaitDownAndSlop method
03-28 14:54:24.942 409 490 D system_server: Start Scrolling Gesture at (1864.063965, 634.830994)
Subsequent differences in the logs occur when looping through the PointerHandlers objects, specifically within the
03-28 14:54:24.943 18081 18081 I SuspendingPointerInputFilter.kt: NEW GINA GINA GINA in forEachCurrentPointerHandler method. pointerHandlers size = 1
03-28 14:54:24.943 18081 18081 I SuspendingPointerInputFilter.kt: NEW GINA GINA GINA calling offerPointerEvent for each pointer handler
03-28 14:54:24.943 18081 18081 I SuspendingPointerInputFilter.kt: NEW GINA GINA GINA pass == awaitPass
03-28 14:54:24.943 18081 18081 I SuspendingPointerInputFilter.kt: NEW GINA GINA GINA resuming event. type = Exit
03-28 14:54:24.943 18081 18081 I SuspendingPointerInputFilter.kt: NEW GINA GINA GINA in forEachCurrentPointerHandler method. pointerHandlers size = 1
03-28 14:54:24.943 18081 18081 I SuspendingPointerInputFilter.kt: NEW GINA GINA GINA calling offerPointerEvent for each pointer handler
03-28 14:54:24.943 18081 18081 I SuspendingPointerInputFilter.kt: NEW GINA GINA GINA pass != awaitPass
03-28 14:54:24.944 18081 18081 I SuspendingPointerInputFilter.kt: NEW GINA GINA GINA in forEachCurrentPointerHandler method. pointerHandlers size = 1
03-28 14:54:24.944 18081 18081 I SuspendingPointerInputFilter.kt: NEW GINA GINA GINA calling offerPointerEvent for each pointer handler
03-28 14:54:24.944 18081 18081 I SuspendingPointerInputFilter.kt: NEW GINA GINA GINA pass == awaitPass
03-28 14:54:24.944 18081 18081 I SuspendingPointerInputFilter.kt: NEW GINA GINA GINA resuming event. type = Press
I currently am diving into determining where this missing item within the pointerHandlers object comes from. Below is the following information from the object that's missing on failed scrolls:
handlerCoroutine info: size = 1030 x 1811; pointerAwaiter = null; awaitPass = Main; currentEvent = {buttons = [toString = PointerButtons(packedValue=0); isPrimaryPressed = false; areAnyPressed = false; isPrimaryPressed = false; isSecondaryPressed = false; isTertiaryPressed = false; isBackPressed = false; isForwardPressed = false; indexOfFirstPressed = -1; indexOfLastPressed = -1]; keyboardModifiers = [toString = PointerKeyboardModifiers(packedValue=2097152); isCtrlPressed = false; isMetaPressed = false; isAltPressed = false; isAltGraphPressed = false; isSymPressed = false; isShiftPressed = false; isFunctionPressed = false; isCapsLockOn = false; isScrollLockOn = false; isNumLockOn = true]; type = Enter; changes = [PointerInputChange(id=PointerId(value=6), uptimeMillis=83137400, position=Offset(540.3, 473.7), pressed=false, previousUptimeMillis=83137400, previousPosition=Offset(540.3, 473.7), previousPressed=false, consumed=androidx.compose.ui.input.pointer.ConsumedData@f3d4df1, type=Mouse, historical=[],scrollDelta=Offset(0.0, 0.0))]}; viewConfiguration = {longPressTimeoutMillis = 400; doubleTapTimeoutMillis = 300; doubleTapMinTimeMillis = 40; touchSlop = 20.0; minimumTouchTargetSize = 48.0.dp x 48.0.dp}; extendedTouchPadding = Size(0.0, 0.0)
je...@gmail.com <je...@gmail.com> #14
I did some more testing on this, and it appears that there has been improvements on both ChomeOS AND Compose:
- With the use of Compose 1.2.0-alpha02 (from the original post) and Chrome version 99.0.4844.86 on a PixelBook....
- The touchpad two-finger scrolling is now working if you tap on the Compose list first
- A physical mouse wheel does NOT work
- Scrolling with a finger on the screen works (as before)
- With the use of Compose 1.2.0-alpha06 and Chrome version 99.0.4844.86 on a PixelBook....
- The touchpad two-finger scrolling is now working if you tap on the Compose list first
- A physical mouse wheel is now WORKING
- Scrolling with a finger on the screen works (as before)
Attached is an updated version of the sample app.... using Compose 1.2.0-alpha06
I have not yet tested other Chromebooks to see if everything is working there also.
gd...@google.com <gd...@google.com> #15
Thanks for the detailed information Jeff! For Compose 1.2.0-alpha06, it looks like we're on the same page with scrolling with a finger and the physical mouse.
For the touchpad two-finger scrolling, I still am unable to consistently scroll (even when tapping on the Compose list). I see the compose scroll failing to work when doing many short/succinct (~ 1 second) two-finger scrolls. After the initial one or two scrolls, the scrolls stop being registered and the compose scroll won't work until I move the mouse again.
We will keep investigating this use case to ensure consistency between the mouse and trackpad experience!
ap...@google.com <ap...@google.com> #16
Branch: androidx-main
commit a3d64d7b89a93177c4012c0266e149d3d1384389
Author: Levi Albuquerque <levima@google.com>
Date: Fri Apr 22 09:28:14 2022
Draggable fix for dropping events
Added a fix to draggable gesture detection. Because of the nature of how
trackpad to touch event chain worked on ChromeOS, some of its interaction with
our gesture detection system caused the forEachGesture loop to miss some events
and this made the trackpad to behave incorrectly. This fix fixes this by looping
the drag cycle inside the awaitPointerScope and relying on the coroutine scope
to eventually cancel/leave the cycle.
Test: Additional test and all previous tests should pass.
Fixes:205373134
Change-Id: I30a88afcc520055dc00ab20fa236209bede5d9db
M compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/gestures/Draggable.kt
M compose/foundation/foundation/src/androidAndroidTest/kotlin/androidx/compose/foundation/DraggableTest.kt
ap...@google.com <ap...@google.com> #17
Branch: androidx-main
commit 7961bf9ef572263be67762476908636d5de4cc11
Author: Levi Albuquerque <levima@google.com>
Date: Thu May 05 14:44:34 2022
(Mouse) Scrollable fix for dropping events
Added a fix to mouse scrollable gesture detection. This is a continuation of
Test: All previous tests should pass.
Fixes: 231431268
Change-Id: I41fe595690a080e3a4f1ba47af212519744b7ee6
M compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/gestures/Scrollable.kt
ap...@google.com <ap...@google.com> #18
Branch: androidx-main
commit 72abfafd3ea61c464101b02ca5c4bb97fa081f7e
Author: Louis Pullen-Freilich <lpf@google.com>
Date: Mon May 23 19:36:05 2022
Fixes some dropped hover events when using Modifier.hoverable
Capturing events from inside awaitPointerEventScope can cause events to be dropped during processing, instead all the work should be done inside awaitPointerEventScope.
This is a similar fix to the fixes for
Fixes:
Test: HoverableTest
Change-Id: Ib51fc4b3f1f1768fec0e3d47af970c1817900636
M compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/Hoverable.kt
Description
Mouse Scrolling does not work with Compose (example: ChromeOS running Android app, connected mouse to mobile device, Samsung DEX, etc)
Jetpack Compose release version: 1.0.3 or 1.1.0-beta02 Android Studio Build: AI-211.7628.21.2111.7824002, 202110141647, Kotlin version: 1.5.30 or 1.5.31
Steps to Reproduce:
Results: Nothing happens
Expected Results: List scrolls with mouse (either mouse-drag or mouse-scroll)
RecyclerView with same type of list works just fine
See sample app (attached)