IssueTracker

Consider this ticket for adding mouse support to LazyColumn. Will be closed when (https://android-review.googlesource.com/c/platform/frameworks/support/+/1837304) is merged.

I just tested Compose 1.2.0-alpha01 and mouse scrolling on ChromeOS is still broken

This feature missed the alpha01 build cut, but it is already merged and will be available in alpha02.

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)

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?

Confirmed with my own test app that external mouse scrolling is still not working with 1.2.0.apha02.

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 }

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:

1. Try to find a ACTION_SCROLL specific code in ARC++, if exists.
2. Try to log motionEvent.getAxisValue(MotionEvent.AXIS_VSCROLL) and motionEvent.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

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)

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!

@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 stored pointerHandler within the SuspendingPointerInputFilter.kt file is empty on scroll attempts that fail. It seems to become noticeable within the dispatchPointerEvent method, which sees pointerHandlers is empty, so it never calls offerPointerEvent.

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 the comparison of these logs using an internal diff tool. However, I've also highlighted the logs in the successful scroll that don't appear in the failed scroll below:

Firstly, the logs first divide when the successful scroll adds an object to the pointerHandlers object.

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 dispatchPointerEvent method. These instances are pasted below:

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)

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.

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!