Created attachment 199385 [details] Screenshot 01 Showing the Issue Version: 25.2.0.3 (X86_64) / LibreOffice Community Build ID: e1cf4a87eb02d755bce1a01209907ea5ddc8f069 CPU threads: 28; OS: Windows 11 X86_64 (10.0 build 26100); UI render: Skia/Vulkan; VCL: win Locale: en-GB (en_GB); UI: en-GB Calc: threaded The issue is as per the 'Summary' title. I have attached three screenshots here which illustrate the issue and how things should be to remedy it.
Created attachment 199386 [details] Screenshot 02a Showing the Issue
Created attachment 199387 [details] Screenshot 02b Showing the Issue (and Remedy)
Don't follow why scroll bar thumb position should follow text you've highlighted. The scrollbar "thumb" object resizes according to document page count and zoom level and represents a "view port" into the document. Clicking in the scroll bar moves the current view port, or the thumb can be dragged. The distance moved by mouse click is determined by the number of pages in the document and zoom level in UI. The scrollbar movement arrows above and below the scrollbar move by ~1 line of text For precise movements, you need to set either a "Reminder" or a "Bookmark" using the Navigator. bug 164745 has been corrected for 25.2.1.2 release, so put SB Navigator into 'Reminder' navigate-by mode and drop Reminders (the Paperclip) where you need to position your view port. You get a rolling stack of 5 to work with. IMHO the scroll bar thumb as representation of viewport into a document is working as designed and as expected. IMHO => NAB and doing anything different is => WF
(In reply to V Stuart Foote from comment #3) > Don't follow why scroll bar thumb position should follow text you've > highlighted. No, you are misunderstanding why I highlighted the text. The highlight was only done for cosmetic reasons to try and make my meanings clear in the screenshots: what line I was referring to. There is no way I was trying to suggest that the highlighted text had any function other than to easily see how the scrollbar line count was working. In all I do think that my point should be taken onboard. As it stands for a text editor Writer is acting in ways on this issue that I have never seen any other text editor work. Gosh even my Firefox browser operates in the way I indicate a scrollbar should work — and Firefox isn't even a text editor. With respect I really do think you should reconsider your decision.
Sure, I'll set it back for UX to kick it round. But still, what UX do you expect? As explained the current "thumb" on the scroll bar represents a view port into the current document, at a specific zoom. That view port--at a given zoom level--will move. By drag of the thumb, by mouse click on the scroll bar, or by click or click-hold on the arrow ends of the scrollbar. Beyond the viewport size relationship, between page count and zoom level, movements of the view port is relative to the view port--not some object/position on the document page. And if you need precise movements, that requires use of Reminder, Bookmark objects in the Document. Or upon the other movement UNO commands, eg. GoToNextPara, GoToPrevPara, GoToNextPage, GoToPrevPage, GoToEndOfDoc, GoToStartOfDoc, and etc. Or possibly shifting Navigator to the 'Recency' navigate-by mode (like a web browsers back button). Point is the Scrollbar controls are not something to focus on for precise positioning within a document.
(In reply to V Stuart Foote from comment #5) > Sure, I'll set it back for UX to kick it round. Okay Stuart. Thank you very much for listening and referring it to another branch in the tree.