IMHO this is unexpected behavior, also reducing Productivity: If you copy come text by marking it with the mouse, the "control-copying" it to the target position, the copied text is still selected. Even if you click at a different text position outside (to relocate the cursor) the selection is still active. That means the first character you type for the new cursor position will erase the text you copied before. (Also seen in 7.3.6.2 running on Linux)
No repro with Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 9b9159aa9073318c6892787d721b8cd732525972 CPU threads: 4; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: cs-CZ (cs_CZ.UTF-8); UI: en-US Calc: threaded Version: 7.3.7.2 / LibreOffice Community Build ID: 30(Build:2) CPU threads: 4; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: cs-CZ (cs_CZ.UTF-8); UI: cs-CZ Ubuntu package version: 1:7.3.7-0ubuntu0.22.04.1 Calc: threaded Please copy and paste here the contents of your Help - About from your LibreOffice. This allows us to know more about your system.
Created attachment 184915 [details] Screenshot Windows: About (In reply to raal from comment #1) > Please copy and paste here the contents of your Help - About from your > LibreOffice. This allows us to know more about your system. From Linux: Version: 7.3.6.2 / LibreOffice Community Build ID: 30(Build:2) CPU threads: 8; OS: Linux 5.14; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
Created attachment 184916 [details] Windows Recording showing the effect I can reproduce the issue in Windows 100%, but in Linux only occasionally. For the recording: Towards the end I first position the cursor at the end by clicking then I press a character (that makes the text inserted before disappear again).
Steps followed to reproduce : 1. Open LibreOffice Writer 2. Pasted some text inside the page 3. Selected some lines of sentences and copied it 4. Clicked on the page(in another place) 5. The text selection marking(blue marking) got vanished. Environment : Windows 10, AMD A series processor, 4GB Ram, 64 bit Result : bug not reproduced. Status : Unconfirmed.
Steps to bugs not reproduce. step1.Open version LibreOfficeDev7.6. step2.Enter any text. step3.Drag to select given text ,than copy on another place.
Seems this has always behaved like this, tested with 7.3, 7.0, 6.0, 4.3, 3.5. Doesn't matter if you ctrl-drag, moving by dragging behaves the same way. Let's ask UX what they think about changing this. One could argue that keeping the selection gives you a visual indication that the operation succeeded.
(In reply to Buovjaga from comment #6) ... > keeping the selection gives you a visual indication that the operation > succeeded. The issue is not that the selection is still active after move or copy is finished, BUT that a repositioning of the cursor (e.g. by clicking) does not clear the selection. So next character entry still does replace the selection.
Keeping the selection allows to reposition after dragging, for example. And provides feedback of what has been. If you click somewhere else the selection will be cleared - but using the keyboard is very effective anyway. It is common behavior and the same on MSO and text editors (at least Kate).
Sorry, I did not notice the uncontroversial point about selection staying after clicking elsewhere. Bibisected with Windows 7.2 repo to https://git.libreoffice.org/core/commit/a2f6b4e8995c149620db4fcfe7e355af4fbc869e tdf#88064 In add mode don't change SetCursor and KillSel functions when shell is popped This is reproducible with all Linux backends as well.
This is really a regression? I rather don't see an issue.
(In reply to Heiko Tietze from comment #10) > This is really a regression? I rather don't see an issue. Only when ctrl-dragging to copy.
(In reply to Buovjaga from comment #11) > Only when ctrl-dragging to copy. Highlights the target likewise dragging without ctrl. I see no issue.
(In reply to Heiko Tietze from comment #8) > (...) If you click somewhere else the > selection will be cleared - but using the keyboard is very effective anyway. Actually not true: If you watch the video closely, there are two spaces at the end of the document, and the text is inserted between those two spaces. Then the end of the document is clocked, leaving one space after the copied selection and the selection is not cleared. So when entering the 'x' at the end, the selected test is removed. The bug is quite significant if you paste, scroll, then enter new text somewhere else: You might miss that your copied text is gone again.
Created attachment 185022 [details] Screencast Linux The selection is cleared for me if I click before the pilcrow or somewhere right of it. Version: 7.4.5.1 / LibreOffice Community Build ID: 40(Build:1) CPU threads: 8; OS: Linux 6.1; UI render: default; VCL: kf5 (cairo+xcb) Locale: de-DE (en_US.UTF-8); UI: en-US 7.4.5-1 Calc: threaded
(In reply to Heiko Tietze from comment #14) > Created attachment 185022 [details] > Screencast Linux > > The selection is cleared for me if I click before the pilcrow or somewhere > right of it. You initiated the drag without holding Ctrl key.
(In reply to Buovjaga from comment #15) > You initiated the drag without holding Ctrl key. It's just an illustration for the working deselection. It's the same whether you copy or move.
(In reply to Buovjaga from comment #9) > Sorry, I did not notice the uncontroversial point about selection staying > after clicking elsewhere. > > Bibisected with Windows 7.2 repo to > https://git.libreoffice.org/core/commit/ > a2f6b4e8995c149620db4fcfe7e355af4fbc869e > tdf#88064 In add mode don't change SetCursor and KillSel functions when > shell is popped Just a note in case it is not obvious: the relation here is that Ctrl + left mouse drag is a shortcut for Add mode selection.
The patch that caused the regression was done to make the adding selection mode work when selected in the status bar selection mode control. Here are a couple patches offered to improve selection experience. The first patch addresses the undesirable need for two clicks to clear the selection after drag and drop with the ctrl key held, described in this bug report. The second patch fixes nit-picks with the selection control icon displayed: https://gerrit.libreoffice.org/c/core/+/146725/1 https://gerrit.libreoffice.org/c/core/+/146726/1
(In reply to Jim Raykowski from comment #18) > The patch that caused the regression was done to make the adding selection > mode work when selected in the status bar selection mode control. > > Here are a couple patches offered to improve selection experience. The first > patch addresses the undesirable need for two clicks to clear the selection > after drag and drop with the ctrl key held, described in this bug report. > The second patch fixes nit-picks with the selection control icon displayed: > https://gerrit.libreoffice.org/c/core/+/146725/1 > https://gerrit.libreoffice.org/c/core/+/146726/1 I built with both patches applied and can confirm both work as intended!
Jim Raykowski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/5bc7cb77df839f7dd3cc7d444490aaf50ebccdc6 tdf#153205 related: Fix selection problems caused by cursor shell It will be available in 7.6.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Jim Raykowski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/9788a565b3241d1bd62394b9e29c322361d05f80 tdf#153205 related: Improve selection mode control icon update It will be available in 7.6.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
@Buovjaga, Thanks for testing! I will set this bug as resolved fixed now that the patches are merged.