Description: When holding and moving a scrollbar the standard behaviour in nearly all (Windows) applications is that the scrollbar will jump back to the position it was in when you clicked on it if you move the mouse far enough away from it. E.g. in Firefox: click-and-hold scrollbar on the right, drag it down, (while still holding the mousebutton down) move the cursor to the left ~120 pixels. Result: scrollbar jumps back to its original position, not moving anymore until you move the cursor closer again. Releasing the button while at 120+ pixels will release and keep the scrollbar at its original position. Why is this useful? For example, to quickly check some data in your page/sheet without losing track of where you were. Steps to Reproduce: 1. Click (and keep holding) the scrollbar 2. Move scrollbar up/down or left/right 3. Move mouse away (perpendicular) from scrollbar Actual Results: Scrollbar keeps moving up/down or left/right along with the cursor Expected Results: Scrollbar should jump back to original position when the mouse is ~120 or so pixels away from it. Reproducible: Always User Profile Reset: No Additional Info: This has been bothering me for a loooong time on several different PCs and LO builds, but I just never took the time to report it. This may seem like a small thing, but it is such a useful feature if you're used to it! Plus, it is the default behaviour in just about every other app out there, shouldn't we want LO to adhere to universal standards like these? Note: I ticked 'Calc' in 'Component', but this is an issue in Writer (and I'm assuming all other apps) as well. Note2: this happens in v7.5.5.2 and also/still in the just updated 24.8.6.1.
Version 25.2.1.2 Build ID: d3abf4aee5fd705e4a92bba33a32f40bc4e56f49 CPU threads: 8; OS: Windows 11 x86_64 UI render: Skia/Raster; VCL: win Locale: en-US; UI: en-US Calc: threaded I do encounter this same behavior. However, this seems to be more of an enhancement request than a bug. Leaving as unconfirmed.
I thought about submitting it as 'Enhancement request', but didn't think it was. Wouldn't you consider something that works a certain way in (as far as I know) literally every (Windows) app *except for LO* a bug?
Might get solved by bug 164656 if we get native scrollbars.
Confirming the the observation: The scrollbar loses focus if the cursor moves away. We don't respect this behavior. Yet. Never seen this on Linux (or macOS).
(In reply to Heiko Tietze from comment #4) > Confirming the the observation: The scrollbar loses focus if the cursor > moves away. We don't respect this behavior. Yet. > > Never seen this on Linux (or macOS). This would be a horrible UX, e.g. to be in the middle of a zoom'd Draw canvas and scroll+release jumps back to previous view. And I would disagree with OP that this is desirable or even present as "the default behaviour in just about every other app out there". For example, it is not implemented globally by MS. Just look at recent Windows Notepad 11.2501.31.0, or Paint 11.2502.161.0 So, if something is implemented (native control or in VCL), it will need to be controllable to toggle it off, per module or globally.
(In reply to V Stuart Foote from comment #5) > This would be a horrible UX... It might become handy when you scroll through a document but need to go back eventually.
>> This would be a horrible UX... How horrible can it be if it is the default in so many apps? Wouldn't you have complaints about those thousands of apps? Wouldn't the internet be full of people complaining about it? > e.g. to be in the middle of a zoom'd Draw canvas and scroll+release jumps back to previous view. No, just scrolll+release doesn't make it jump back, it's moving the cursor away from the scrollbar that does. And (assuming you haven't released - and if you did, then that's on you) in that case you'd only need to move the cursor back closer to the scrollbar and it jumps to the cursor's position again. > And I would disagree with OP that this is desirable or even present as "the default behaviour in just about every other app out there". Desirable is subjective, of course, but this feature is objectively present in just about every app. When there's thousands that work that way, just 2 recent apps that don't follow that behavour don't invalidate that. (And come on, it's MS, they have a habit of not follwing their own OS' standard in their apps; I could write a book about all the things wrong with MS Office.) > It might become handy when you scroll through a document but need to go back eventually. Exactly! If you're used to it jumping back, this is a really handy feature. (But I can imagine that if you never use it it might seem more trouble than helpful.)
Windows only? And not widely accepted [1][2][3], though I see it on a couple of comparable to Writer Windows only based editors, e.g. Notepad++ and BablePad Seems to be a MS Windows only "feature", I certainly don't find it useful. Maybe Mike or Tomaž knows where it lives in the win32 or WinUI native calls, but I don't see doing this for the Windows builds as an imperative. And it probably couldn't be done cross-platform. -1 and => WF =-ref-= These are all for Windows users, no macOS no Linux/DE represented. [1] https://learn.microsoft.com/en-us/answers/questions/344507/back-snapping-of-the-scroll-slider [2] https://ux.stackexchange.com/questions/55623/why-do-scrollbars-revert-to-original-scroll-distance-when-mouse-is-dragged-sidew [3] https://www.reddit.com/r/Windows11/comments/1dquuq4/is_there_a_hack_to_disable_scroll_bar_snapback/