Description: When selecting a very-long paragraph by triple clicking at it, Writer always jumps to the end of the paragraph, causing uncomfortness of reading, compared to Word/Pages which will hold the position of screen. Steps to Reproduce: 1.Make a long paragraph which could overfit one screen. 2.Scroll up to ensure that the end of the paragraph is out of screen. 3.Try to tripple-click at the paragraph. Actual Results: The screen immediately scrolls to the end of the paragraph (where the cursor jumps to), instead of staying at where it was. Expected Results: Staying at where it was should be more friendly while reading or presenting. Reproducible: Always User Profile Reset: No Additional Info: Could take Word or Pages as examples.
Don't see the point, if you are making a selection of a text paragraph (with quad-click; triple selects sentence, double selects single word) are you editing or not? I prefer to see the end of a selection that I've just made and for the view port to follow the position of the edit cursor, and not to retain the view port with the edit cursor positioned off screen. And, this is consistent. If you select a sentence that extends out of current view the cursor advances to the end of the sentence and the view will also adjust. Paragraph selection does the same, advancing view port to track the edit cursor--that is preferred for effective editing UX. IMHO => WF
I reproduced this bug successfully. Version: 7.5.4.2 (X86_64) / LibreOffice Community Build ID: 36ccfdc35048b057fd9854c757a8b67ec53977b6 CPU threads: 8; OS: Windows 10.0 Build 22621; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded
(In reply to V Stuart Foote from comment #1) > Don't see the point, if you are making a selection of a text paragraph (with > quad-click; triple selects sentence, double selects single word) are you > editing or not? > > I prefer to see the end of a selection that I've just made and for the view > port to follow the position of the edit cursor, and not to retain the view > port with the edit cursor positioned off screen. > > And, this is consistent. If you select a sentence that extends out of > current view the cursor advances to the end of the sentence and the view > will also adjust. > > Paragraph selection does the same, advancing view port to track the edit > cursor--that is preferred for effective editing UX. > > IMHO => WF Lol exactly I've neither no idea why I love to triple-click at something freqently, especially during *deep thinking* between typing. This's true, the concentration works as far as me feel so. The *deep thinking* is the key reason why I would recommend this - you simply don't want your text fly away while you are staring and brain parsing at it. Anyway, considering Word and Pages do hold screen position, maybe, just say, they've also realized this, too? That some users just love to select while reading? Something phsycological? While another point, I don't think it's very neccessary to scroll to the end of the paragraph while user triple clicking at a paragraph. What will they actually do next? Applying format? Deleting it? It'll be better WYSIWIG if screen holds its original position, isn't it?
Not a bug, it is and enhancement request under UX review.
Selecting a sentence that extends to the next page does the same. sw/source/uibase/wrtsh/select.cxx contain word, sentence, paragraph, and entire document selection functions for Writer. If it is decided to change the current behavior to not scroll to the end of the selection, doing what the SelAll function does to prevent this should also work for the SelSentence and SelPara functions.
MSO selects a word per double-click, and the paragraph on triple, we do word -> sentence (not line) -> paragraph. And while we keep the caret visible and put it on the end of the selection, MSO hides it completely -- and keeps the view port. I agree that changing the view port (whether scrolling to the next page or to the line end in case you have zoomed in) is at least surprising. But as Stuart mentioned it is also a safety measure since you get feedback of what has been selected. Similar request in bug 137603 to "Keep cursor position on SelectAll" (with some duplicates). We do not scroll to the end of the document on ctrl+a / select all until attributes have changed.
We discussed this topic in the design meeting and decided to make it a duplicate and comment there. *** This bug has been marked as a duplicate of bug 137603 ***