I just bought a Asus C302 Flip Chromebook, Google Chrome OS Version 63.0.3239.116 (Official Build) (64-bit). It cannot use my Logitech unifying receiver as it does not have a USB-A port. So I decided to use a bluetooth mouse.

I bought a Logitech MX Master 2S bluetooth mouse. Most of the time a single mouse scroll click would scroll the page a line or 2. However, every now and then (1 out of 10?) it would jank; ie: jump many pages; often to the end of the document. This meant I lost my place which is very disruptive to reading :-( and I would have to scroll _carefully_ back. I tried seeing if I could get used to it but it was so bad that after less than 1 hour of use I returned the mouse to the store.

I then tried a Microsoft Sculpt Bluetooth mouse. Better but still janky. I did discover that I could significantly reduce the jank if I wiggled the mouse right-left before scrolling. It seems to me that when wiggling the mouse the cursor janks which is far less irritating than having the page move to a random location. While wiggling the mouse reduces the scrolling jank it is annoying to have to do this and the scrolling can still be janky.

I also tried the Microsoft Sculpt Bluetooth mouse on a Lenovo 13 Chromebook, Google Chrome OS
Version 63.0.3239.116 (Official Build) (64-bit). A wireless mouse scrolls perfectly. The Microsoft Sculpt bluetooth mouse is less janky but still the jank is noticeable.

Once I get a USB-A to USB-C adapter I'll try a wireless mouse on the Asus C302.

My suspicion is the initial bluetooth channel scroll event is delayed and until a second scroll event. Because of the 2 scroll events appear to happen together (ie: very quickly) the software interprets this as a fast pair of events (fast scroll) and logically accelerates the scrolling.

I got a wireless mouse and a USB-A to USB-C adapter. Mouse scrolling with a Logitech M510 wireless mouse works perfectly.

@pbathini, can you see if you can reproduce this? 

Hi Brian, here is my guess. The bluetooth device would go into sleep mode to save power when you do not use it for a while. The time to wait before going into sleep mode varies with the peripheral devices. 

When there is any mouse event to send, the device is waken up and tries to reconnect to the host (chromebook). The reconnection takes time, usually a few hundred milli-seconds. Hence, the events would be piled up quickly and lead to the janky behavior that you observe.

If you wiggle the mouse a bit before scrolling, the cursor movement would trigger the mouse to reconnect. So when you scroll, the scroll events would not pile up and can be sent smoothly.  If you keep using the mouse, the scrolling should keep smoooth because the bluetooth connection is still maintained.

It seems to me that this is a limitation caused by the power saving nature in the peripheral device.

When you wiggle the mouse, do you observe that there is an initial cursor jump since the cursor movement events are piled up initially?

I agree with your thoughts: events pile up.

Wiggling the mouse does seem to generally stop the janky behavior. However this is not an attractive solution. At best this is a work around. Do we really want to publish help on how to do this work around? I did this wiggling and doing it was very annoying.

I agree that the event pile up is most likely a problem caused by the peripheral device.

However, I believe the critical issue is not the event pile up. 

I believe the critical issue is: 

  * when the driver sees 2 or more scroll events coming quickly
  * the driver "accelerates" the scrolling

This acceleration "flings" the page to a new location and the user loses any idea of where they are in the page. If the driver simply handled the 2 scroll events as 2 simple scroll events then there would be a slight delay and the page would move a couple small amounts. While a slight delay is not "perfect" it would be far better than having the page scrolled to a random location.

Would it be possible for the bluetooth driver to detect "events have piled up" and not always do the accelerated "fling" movement? 

Maybe for piled up events:

  * 1-2 events would be normal scrolling
  * 3 events would be a "page"
  * 4+ would be a "fling"

Here below are what I personally thought about the piled up events.

The scroll events are sent from the peripheral to the host without timestamps. When the events pile up, they look pretty much the same as a quick scroll. Hence, the input driver is doing its job correctly by generating a big scroll.

How many scroll events are piled up are highly device and environment dependent. The latency depends on how long to wake up the peripheral device from its sleep mode (this varies from device to device), how long it takes to reconnect (this depends on how noisy the environment is), and how long the host responds to the reconnection request (the host bluetooth controller may nor may not be busy with other events and may also need to compete the RF antenna with wifi).

On the host side, I am not sure if it is possible to massage the input events to mitigate the issue. Let's include adlr@ for more insight about how the input layers could handle the piled up scroll events.

As a user I am often scrolling a single click of the scroll wheel. This single click scrolls the page a small amount. However, if there is a pause between clicks *and* I don't wiggle the mouse *and* I accidentally click 2 clicks then the page is accelerated/flung to a random location. 

From my perspective: simply not accelerating on *2* scroll events would solve the most of the pain and still allow flinging for larger sets of scroll events.

Also having issues with this and the Microsoft Designer Bluetooth Keyboard and Mouse on a Chromebook Pixel 2 laptop (Version 64.0.3282.87 (Official Build) beta (64-bit)). 

Scrolling the mouse 1 click moves the page down ~1 line as it should. Continued scrolling causes uncontrollable jumps to random spots though. This doesn't seem to be related to sleep for me -- I can be scrolling 1 line at a time, then speed up my scrolling and immediately the page skips to a random location.

emilross - as a test can you try wiggling the mouse every time before a scroll?

a possible solution is to not allow acceleration if the last mouse input was longer than a certain time; eg, if the last mouse input was 0.1 or longer than do not allow acceleration.

0.1 sec

Now on Version 65.0.3325.65 (Official Build) beta (64-bit).

Yes, wiggling the mouse before scrolling seems to be a workaround, I don't see the issue when I do that.

My somewhat educated guess is:

1. without activity the Bluetooth transmitter powers down to conserve battery

2. it takes a while to power back up and establish communications

3. while the Bluetooth is not ready any mouse events queue up (rather than being discarded)

4. once the Bluetooth is ready all queued events are sent as fast as possible

5. the Chrome OS driver looks at the time between events to tell if acceleration should be done and by how much

6. when the power up queued events arrive the Chrome OS driver interprets the events as an extremely fast activity by the user and accelerates inversely to the time between each event. Because the time between events is short massive acceleration is used.

Note:
Wiggling after a delay causes the cursor to accelerate wildly around the screen. *Importantly* the cursor stays visible on the screen. Further wiggling reveals the cursor location. Wiggling also wakes up the Bluetooth which is why random scrolling does not occur after wiggling.

Scrolling the page after a delay causes the scrolling to accelerate wildly, *Importantly* this scrolls the page to a random position and the user has no easy way to find their previous location.

This condition can be detected in the Chrome OS driver by not accelerating if the previous event happened long enough ago that the Bluetooth might have powered down; perhaps 0.1 - 0.25 seconds.

By my estimate a fast scroll takes 0.25+ sec per stroke so this would still allow fast scrolling.

I have had the same experience on Chrome OS 64.0.3282 with a PixelBook.

Using Logitech G603 and an MX Anywhere 2 via Bluetooth. I have posted my experiences in here: https://bugs.chromium.org/p/chromium/issues/detail?id=805835