https://bugs.documentfoundation.org/show_bug.cgi?id=109272
--- Comment #27 from Mike Kaganski <[email protected]> --- (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. -- You are receiving this mail because: You are the assignee for the bug.
