It's not clear that this is caused by the same effect. A commenter suggests that this behaviour is actually due to how mouse acceleration affects scrolling speed which I am more inclined to believe.

Yeah there is no way this has anything to do with the same behavior. What's likely happening is there's a delay in auto-scroll, and by generating new mouse events your triggering manual scrolls at a higher rate (or in addition to?) than auto-scroll.

I think it is not acceleration, but rather a position of mouse relative to the edge of a window.

I think you'll find that Shift + Page Down is the fastest way to mark a lot of text, since you're doing it page by page instead of character by character.

Or, since GP said "mark all text", use Ctrl/Command+A.

Of course neither of these would demonstrate the effect they were talking about.

  ggVG

I typed that into Notepad and it did exactly what I expected: it displayed 'ggVG' in the edit window. I can even save it to a file!

Thank you for the tip.

I've implemented the behavior of "scroll the field down while the user is holding something selected" before, and my initial implementation had this bug, so I think I can explain a likely reason this happens. My code listened to mouse movement events, and if a selection was present and the mouse was moved into the top or bottom regions of the scrollable area, then the area would scroll a bit, and a recurring timer for some number of milliseconds would be started (if already active, then it would be reset) which would case the area to scroll a bit more. (This timer would be canceled if the mouse was moved out of the auto-scroll region.) If you continually moved the mouse, then it's possible the application would get the mouse movement events at a higher rate than the timer would fire, so the scrollable area would scroll faster. I think I found out that the platform would emit the mouse movement events at up to 60fps, so I just tweaked the timer to match that. Not a perfect solution, maybe I'll update it eventually to check the system time and scroll slower if the mouse move events are arriving faster than the timer.

I don't know the reason for that, but like the cursor to mark the progress bar method above, I do this trick to this day. You don't have to highlight first, you can just highlight as you go, wiggle the mouse outside of the bounds of the window, and then deselect when you get where you're going. And it's not just in Notepad, I do this in a programmers editor too.

Isn't it funny that many of us learned these sames ways of interacting with computers without being explicitly taught. If this were on the Internet, I would say it's a way to gauge whether you're a robot, but otherwise, it's just a measure of my impatience. Maybe it's just an acquired skill from growing up playing video games.

Strange but mine doesn't scroll UNLESS I move the mouse. I wonder if this is because I have the "Adjust for best performance" option set?

This applies to Macs as well. Or at least it used to, in some situations — now that I think about it, I can't really recall the last time I did that. The standard behaviour now seems to be scrolling faster the farther the mouse is from the edge of the pane (which is clearly a deliberate, and useful, UI decision).

I had completely forgotten about the mouse-wiggling trick! It's just one of those things I used to do without thinking about it. It makes sense that an event loop was waiting for an event to fire.

Are you suggesting it’s faster or slower when you wiggle the mouse? If it’s slower it could be because you put more events in the event queue that have to be pumped.

It even works on my latest Firefox beta on Windows 10 (on this HN page). Hmm...They may not the same thing.