Description: When editing a multi-page document, using the X clipboard to copy text between pages causes an unwanted display jump from the page where the text was pasted back to the page from which it was copied. This is inconvenient for its own sake (since the user typically wants to continue editing where he just pasted the text). The problem is compounded by the fact that the original text remains selected, so that if the user then starts typing the original text is deleted. This behavior is inconsistent with the that of most (all?) other programs that support the X clipboard. It's also inconsistent with the behavior of Writer itself when the copy-and-paste is done via the ctrl+C, ctrl+V keystroke sequences. The current behavior is this: * Middle-click pastes the selected text at the mouse pointer position * The display jumps back to display the page with the previously-selected text * The previously-selected text remains selected Typically, the user must then manually de-select the text at its original position and then manually return to the page where he pasted it in order to continue editing there. To improve this, it would be useful to change the middle-click behavior to be consistent with other programs that support the X clipboard: * Middle-click pastes the selected text at the mouse pointer position (as it does currently) * The display does not jump when the text is pasted * The selected text that was copied is de-selected * The text cursor moves to a position just after the pasted text With these changes, it should be possible for the user to select text on one page of a document, scroll to another page, middle-click to paste the selected text, and continue typing without any additional steps. Steps to Reproduce: 1.Open a multi-page document in Writer 2.Select some text on the first page 3.Scroll down a few pages and middle-click to paste the selected text Actual Results: Writer jumps back to the the first page of the document. The selected text is still selected. Expected Results: Writer does not jump the display (it remains where it was when the user middle-clicked). The text cursor is positioned immediately after the pasted text. The previously-selected text is de-selected. Reproducible: Always User Profile Reset: No Additional Info: This was found and tested on various Linux distros running various versions of LibreOffice (it's a pretty old bug). It presumably happens on all Writer versions running on X. The obvious workaround is to use the ctrl+C, ctrl+V clipboard and just accept the efficiency hit.
Thank you for reporting confirmed on master: Version: 6.3.0.0.alpha0+ Build ID: 98630a0bd49bd80652145a21e4e0d0ded792b36b CPU threads: 4; OS: Linux 4.4; UI render: default; VCL: gtk3; TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2019-05-04_04:44:35 Locale: tr-TR (tr_TR.UTF-8); UI-Language: en-US Calc: threaded
Jut to say it short, a jump happens on paste using the middle mouse button: Steps to Reproduce: 1.Open a multi-page document in Writer 2.Select some text on the first page 3.Scroll down a few pages and middle-click to paste the selected text Actual Results: Writer jumps back to the the first page of the document. The selected text is still selected.
Still present on 7.0.x.
Yes, I would have reported this too at some stage, as it's quite annoying - especially if the selection is pages up or down from the place to be pasted! One has to think, Oh my knitted socks! if I paste this with middle mouse button somewhere where the selection is not visible then the page is going to jump back to the selection, requiring scrolling again. It is probably true that when someone selects text and pastes it onto a line it is because edits are currently being done at that line, so to jump back to the selection is irrelevant.
Dear ckoresko, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
I tested LO version 3.3.0 Writer (amd64) and the current 7.5.5.2 Writer, both on Debian 12, and confirmed that the same issue was present in both the current and the ancient versions.