Description: In change-tracking, if Show Changes mode is set, the cursor is placed at the right end of a selection after it is deleted using Backspace. Steps to Reproduce: 1. Open a writer document. 2. Insert a word. 3. Turn on Track Changes mode. 4. Select the whole word and delete it using Backspace. 5. The cursor is at the right end of the word. Actual Results: The cursor is at the right end of the word. Expected Results: The cursor should be at the left end of the word. Reproducible: Always User Profile Reset: No Additional Info: User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36
Both in case of backspace/delete the cursor ends up on the side of the selection where it initially was (provided there's a selection), and I'm not sure that's an issue.
Created attachment 135331 [details] Left cursor I cannot reproduce it as you can see in the attached image Version: 5.1.4.2 Build ID: 1:5.1.4-0ubuntu1 CPU Threads: 1; OS Version: Linux 4.8; UI Render: default; Locale: en-US (en_US.UTF-8) Description: Ubuntu 16.04.2 LTS
Halima, the behavior depends on the cursor position before hitting backspace/delete. If you selected the text from left to right, and the cursor is on the right side, then it'll stay there after hitting backspace/delete. On the other hand if you selected it from right to left, and the cursor is on the left side, it'll stay there.
(In reply to Aron Budea from comment #3) > Halima, the behavior depends on the cursor position before hitting > backspace/delete. If you selected the text from left to right, and the > cursor is on the right side, then it'll stay there after hitting > backspace/delete. On the other hand if you selected it from right to left, > and the cursor is on the left side, it'll stay there. That's interesting. There are other ways to make a selection. E.g., one can select a word by double-clicking on it. How is the cursor position after deletion defined in this case?
(In reply to Rosemary Sebastian from comment #4) > That's interesting. There are other ways to make a selection. E.g., one can > select a word by double-clicking on it. How is the cursor position after > deletion defined in this case? It is the same place where it was before the deletion, that seems to be universal. This, and my comments above are based on observation btw, so if anyone knows exactly how it's supposed to work, I'm curious about it as well.
Bug 103458 is related. You may have a look at it.
Bug 103458 covers two bugs actually - wrong cursor position and the fact that currently we can delete stuff multiple times in change-tracking mode. I pointed to the bug report because you didn't seem convinced. The universal behaviour is that the cursor is at the start of a selection after deletion, taking into account how it works in LibreOffice without change-tracking enabled. That we have a cursor associated with a selection looks like another bug, but I am not sure.
To me where the cursor ends up after deletion with change tracking seems like a minor detail, as it doesn't affect the behavior, unlike when change tracking is disabled. I can accept either decision, but can't establish what would be the choice. I checked Word for reference, there deleting selection with change tracking is according to your expectation: depends on whether the key was backspace/delete. Do we want to behave the same way as Word? There seems to be another interesting (unrelated) difference in how change tracking works in Word: if you have part of a word selected, and start typing (thus replace the selected part), then Word replaces the whole word with your typing and the unchanged part, not only the selection.
(In reply to Aron Budea from comment #8) > To me where the cursor ends up after deletion with change tracking seems > like a minor detail, as it doesn't affect the behavior, unlike when change > tracking is disabled. I can accept either decision, but can't establish what > would be the choice. I am not claiming to be a LibreOffice UX expert. But I do think the current behaviour is unnecessarily complicated.
Edit: Expected behaviour: The cursor should always be at the start of a selection after deletion. It should not depend on how a selection is made or how the selection is deleted.
Unlike Microsoft Word where the final cursor position depends on the action we keep the position where it has started (Aron explains in detail at c3,c8). Kind of academic question to me voting for WONTFIX. Any other opinions?
No further opinion, so let's keep the LibreOffice way.
*** Bug 149873 has been marked as a duplicate of this bug. ***
(In reply to Rosemary Sebastian from comment #10) > Edit: > > Expected behaviour: > > The cursor should always be at the start of a selection after deletion. It > should not depend on how a selection is made or how the selection is deleted. I fully agree: It's pretty rather inconsistent. 1. Select some text from right to left 2. CTRL+X 3. CTRL+Z -> changes selection from left to right 4. CTRL+X -> cursor at the right In this case the undo should remember how the text got select in the first place. The alternative would be to make it independent of selection (from left to right/ or right to left). I personally prefer the latter. I personally don't take record of how I select things. And well if I want to replace a start of a word I select from left to right. And if I want to replace the end, I select right to left. Cursor position unpredictability is disruptive, to me, IMHO. Similar type of issue bug 137972 It also matters for track changes with changes visible. Do you type left/right of the deleted word. See bug 149873. The mixture of both doesn't improve the reading of changes. And you can be unaware of the effect with show changes disabled. Setting to UNCONFIRMED for now, because I would like some fresh input
Let's get some fresh input, then. Adding another relevant report to See Also.
Created attachment 184919 [details] Screencast LibreOffice Whether (forward) delete or (backward delete) backspace, we continue where the cursor was last.
Created attachment 184920 [details] Screencast MSO MS Office includes the paragraph break, which makes it hard to compare. If I select a word from left to right or vice versa makes no difference in overtyping, it always continues right of it. But if I exclude the PB and delete per backspace I start from left while after deleting with delete it starts right.
*** Bug 149854 has been marked as a duplicate of this bug. ***
We discussed the topic in the design meeting. The current implementation is straight-forward and keeps the cursor at its place. But given the large number of complaints in see-also and duplicates it seems user struggle to realize the behavior. Changing it and always placing the cursor behind the modification if track changes is active is beneficial, at last for migrating from Windows.
*** Bug 137972 has been marked as a duplicate of this bug. ***
*** Bug 141693 has been marked as a duplicate of this bug. ***
*** Bug 148219 has been marked as a duplicate of this bug. ***
*** Bug 148813 has been marked as a duplicate of this bug. ***
(In reply to Heiko Tietze from comment #21) > *** Bug 137972 has been marked as a duplicate of this bug. *** @Heiko Are you certain about bug 137972 and bug 141693 being a duplicates of this one? Those are cases without track changes involved
(In reply to Telesto from comment #25) > Are you certain about bug 137972 and bug 141693 being a duplicates... Nothing is certain except death and taxes. On the plus, the more duplicates a ticket has the more attention it receives. But feel free to un-duplicate the spell-checking variants. At least we should keep an eye on it once a patch is submitted.
(In reply to Aron Budea from comment #8) > To me where the cursor ends up after deletion with change tracking seems > like a minor detail, as it doesn't affect the behavior, unlike when change > tracking is disabled. (In reply to Heiko Tietze from comment #11) > Kind of academic question to me voting for WONTFIX. (In reply to Heiko Tietze from comment #19) > The current implementation is straight-forward and keeps the cursor at its > place. It is good that the decision was still "let's do it". However, the very idea that it is just a matter of implementation, and that the behavior is unchanged either case, is wrong. (In reply to Rosemary Sebastian from comment #6) > Bug 103458 is related. You may have a look at it. I do hope that you had a look at it. And now think not about the single action, but in a sequence of actions. When user presses Backspace, and then moves somewhere else, it might seem OK either way. But often, the first backspace is followed by more backspaces. Now compare two cases (change tracking enabled, of course): 1. When you have "word", put cursor after "d", and press Backspace four times. 2. When you have "word", *select* "d" left to right, and press Backspace four times. The results would be different. One could tell, that this needs the mentioned bug 103458 fixed. If so, then still the behavior after the first Backspace would be absolutely counter-intuitive, basically wrong: the cursor was placed *at the right of deleted "d"*, but the next backspace removes the character that is not adjacent. And what if you select more than fits to screen? Your cursor is on screen, and you even don't see what will be removed next by the following Backspace. Clear bug.
Ok, so where were we?
Please refrain from changing the summary to some nonsense.
(In reply to Aron Budea from comment #29) > Please refrain from changing the summary to some nonsense. Don’t forget to mention VPN somewhere. >_<
About Cyril Bassington-Bassington. That’s all of them.
(In reply to Mike Kaganski from comment #27) > (In reply to Aron Budea from comment #8) > > To me where the cursor ends up after deletion with change tracking seems > > like a minor detail, as it doesn't affect the behavior, unlike when change > > tracking is disabled. > > (In reply to Heiko Tietze from comment #11) > > Kind of academic question to me voting for WONTFIX. > > (In reply to Heiko Tietze from comment #19) > > The current implementation is straight-forward and keeps the cursor at its > > place. > > It is good that the decision was still "let's do it". > However, the very idea that it is just a matter of implementation, and that > the behavior is unchanged either case, is wrong. > > (In reply to Rosemary Sebastian from comment #6) > > Bug 103458 is related. You may have a look at it. > > I do hope that you had a look at it. > And now think not about the single action, but in a sequence of actions. > When user presses Backspace, and then moves somewhere else, it might seem OK > either way. But often, the first backspace is followed by more backspaces. > > Now compare two cases (change tracking enabled, of course): > > 1. When you have "word", put cursor after "d", and press Backspace four > times. > 2. When you have "word", *select* "d" left to right, and press Backspace > four times. > > The results would be different. > > One could tell, that this needs the mentioned bug 103458 fixed. If so, then > still the behavior after the first Backspace would be absolutely > counter-intuitive, basically wrong: the cursor was placed *at the right of > deleted "d"*, but the next backspace removes the character that is not > adjacent. And what if you select more than fits to screen? Your cursor is on > screen, and you even don't see what will be removed next by the following > Backspace. > > Clear bug. I bet you’re still in your bathrome.
(In reply to Heiko Tietze from comment #19) > We discussed the topic in the design meeting. > > The current implementation is straight-forward and keeps the cursor at its > place. But given the large number of complaints in see-also and duplicates > it seems user struggle to realize the behavior. Changing it and always > placing the cursor behind the modification if track changes is active is > beneficial, at last for migrating from Windows. Ge-cko.
https://gerrit.libreoffice.org/c/core/+/162240
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/c80606bb23fd42e41710d70a96b7ffaf948384a6 tdf#109272: make sure that Delete / Backspace move cursor correctly It will be available in 24.8.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.
Sebastian, thanks for reporting, and Mike, thanks for fixing this. Now, it doesn't matter the point of starting of the selection: after delete, the cursor will be moved to the beginning of the word deleted in track changes. Good in Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 4d0f2d5ec9f7f988a1493916ae35bac1986c95a8 CPU threads: 16; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded Bad in (just for testing in comparison) Version: 7.6.2.1 (X86_64) / LibreOffice Community Build ID: 56f7684011345957bbf33a7ee678afaf4d2ba333 CPU threads: 16; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded
Miklos Vajna committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/261999bc552516a7dae0f96895259485e9ac77a2 tdf#109272 sw: add form filling testcase It will be available in 24.8.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.
Mike Kaganski committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/3ca52750661cf8a3b36a42a0a6d293318232f1b9 tdf#109272: make sure that Delete / Backspace move cursor correctly It will be available in 24.2.3. 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.