Vertical scroll bar keeps jumping to the bottom of the screen

My current workaround is to use a different mouse, a Logi M240. This is pretty much the bottom of the line for Bluetooth mice, making me suspect there's a race condition somewhere in the morass of code which mucks around with mouse events and it's somehow helpful *not* to have events being rapidly thrown by a high-spec mouse? Well I don't think this defect will be "fixed" by the community but it's now biting me only once in a while (with a right-click menu popping up spuriously, or a left-button drag persisting after I had released the left button). I don't play real-time games so these occasional bites don't have fatal consequences

... although I did have some trouble regaining control of my system after an inaccurate drag-and-drop into a folder caused a few hundred files (totalling more than 10 GB) were plopped onto a OneDrive queue for synching (which soaked up the entirety of my flaky 4G data connection because I hadn't gotten-around to figuring out how to rate-throttle that gluttonous beast)... but I have rate-throttled it now. Always a good idea to close the barn door after the horses have bolted once, as they might do it again! ;-)

Microsoft - when is this issue going to be fixed?????? I have tried all the suggested solutions - no resolution for me.

Yes, that works. But then the print is too small.

OK, since the mouse-stutter defect was resolved on my platform by shifting to a different mouse, and since it also arises on at least one rodent-free platform, I now have a new theory about the root cause.

Under my new theory: switching to a different pointing device *might* be an adequate workaround for your platform. No guarantees.

tl;dr

Some process may be corrupting the event queue in Windows, perhaps by "peeking" at a mouse event on the raw-input queue, then pushing it back onto the queue after determining (quite possibly correctly) that this event really "should" be handled by some other process. Due to a race condition (?) some other process also gets a copy of this mouse event, and then pushes its copy onto the queue. Hey presto, there may now be three events for a single mouse click or scroll. (Why three? Well unless the RIDEV_NOLEGACY flag is set when a process registers its "raw input" handler for the pointing device, the mouse's driver will still put a "legacy" event on the queue every time the mouse's status changes.) My source for this tech-geek info is

https://ph3at.github.io/posts/Windows-Input/

Weakly supporting evidence for my new theory is that for some months now my platform has been pretty iffy about restoring its mouse device after it goes into one of its deeper modes of sleep/hibernation. It's more than a bit awkward to use the Windows GUI without a pointing device, but it's possible... and usually I can "manually" bash the OS around until it deigns to load a functional stack of mouse drivers. Sometimes a reboot is required. Sometimes it seems I must disable and then re-enable Bluetooth before I'll get any joy (last night was especially annoying, with a Bluetooth mouse that would momentarily be accepted by the OS only to be shown as disconnected a fraction of a second later.)

All to say that I think there are some gnarly race conditions that'll have to be sorted before this defect is put to rest.

In the meantime (and it may take the Windows QA team quite a while to localise & repair this defect if it is indeed a race condition), I'm suggesting that a viable workaround for your platform *might* be to switch to a different pointing device.``