Bug 103458 - When tracking changes, backspacing over a deleted word should skip over it instead of moving inside it
Summary: When tracking changes, backspacing over a deleted word should skip over it in...
Status: RESOLVED WONTFIX
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.1.5.2 release
Hardware: All All
: medium minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Track-Changes
  Show dependency tree / graph
 
Reported: 2016-10-24 11:22 UTC by Ulrich Windl
Modified: 2024-01-18 09:36 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:

Attachments
Screencast showing the (d)effect (557.06 KB, video/webm)
2023-01-27 07:31 UTC, Ulrich Windl 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Ulrich Windl 2016-10-24 11:22:54 UTC 
If you double-click a word in the middle of a sentence, and then press backspace to delete it, the following happens with "record changes" enabled:
The word deleted is striked through, and the cursor is at the end of the deleted word (OK so far).
Now if you continue to press backspace, the cursor moves like deleting individual characters of the word that is overstriked (effectively "deleting" what is already deleted). Unsure whether this causes further harm internally...
The correct thing would be to delete the character that precedes the deleted word.
Comment 1 Buovjaga 2016-11-06 10:16:01 UTC 
(In reply to Ulrich Windl from comment #0)
> The correct thing would be to delete the character that precedes the deleted
> word.

Ok, in other words skipping backwards over the deleted word. I guess it would be intuitive.
Comment 2 QA Administrators 2017-11-07 07:28:43 UTC Comment hidden (obsolete)
Comment 3 Roman Kuznetsov 2019-01-26 12:07:31 UTC 
still repro in

Версия: 6.1.4.2
ID сборки: 1:6.1.4-0ubuntu0.18.10.1
Потоков ЦП: 4; ОС:Linux 4.18; Отрисовка ИП: по умолчанию; VCL: gtk3_kde5; 
Локаль: ru-RU (ru_RU.UTF-8); Calc: group threaded

but it needs to retest it in current master (6.3) because in 6.3 were some changes in track changes mechanism
Comment 4 Buovjaga 2019-01-26 12:56:55 UTC 
Still repro

Arch Linux 64-bit
Version: 6.3.0.0.alpha0+
Build ID: 1a5340788639ba71725338ddc5d340b2b304f4c2
CPU threads: 8; OS: Linux 4.20; UI render: default; VCL: gtk3; 
Locale: fi-FI (fi_FI.UTF-8); UI-Language: en-US
Calc: threaded
Built on 26 January 2019
Comment 5 QA Administrators 2021-01-26 05:11:34 UTC Comment hidden (obsolete)
Comment 6 Ulrich Windl 2021-01-26 07:29:21 UTC 
In 6.4.7.2 backspacing over a deleted word just does nothing, i.e.: the cursor does not move at all.
Comment 7 QA Administrators 2023-01-27 03:25:15 UTC Comment hidden (obsolete)
Comment 8 Ulrich Windl 2023-01-27 07:31:52 UTC 
Created attachment 184954 [details]
Screencast showing the (d)effect

(In reply to QA Administrators from comment #7)
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

On the screencast: a word left from the cursor was deleted before (so it really does not exist any more). However when deleting via "backspace" key from further right, the cursor is moved inside the word deleted already as if it were still there.

Can you delete a word multiple times???
Comment 9 Mike Kaganski 2024-01-18 06:22:03 UTC 
IMO, this is not a bug.
1. There is no harm created by the current behavior. Deleting something several times does not break the document, nor creates anything in the current redlines.

The alternatives could be:

* on Backspace, stay after the deletion, and eat one character before the deletion (seemingly what is asked in comment o in "The correct thing"). This is wrong: the backspace would then eat something not adjacent; you may even have a situation, when an already deleted part is large, and the place where you actually delete things is outside of the view.

* on Backspace, jump to before-the-existing-deletion, and delete one character there. Still not ideal. The first deletion will still be non-adjacent to the initial cursor position.

* on Backspace, jump to before-the-existing-deletion, and do nothing on this first keypress. It would be somewhat better - but it would be conceptually no different compared to the current situation: the first keypress would "delete the deleted piece again".

Just moving back is something users naturally expect from Backspace; Word does the same.

Since 2016, there was no duplicates for this; not a single new user CCed to this (only OP and Ilmari from TDF are there in the list). No sign of a real user demand.
Let me close it WONTFIX.
Comment 10 Ulrich Windl 2024-01-18 07:44:55 UTC 
Conceptually deleted text is not there any more, but Writer treats it as if it's still there (and I think that's wrong). I made an additional test:

Delete a word and replace it with a different one. Now when searching you can find both the deleted one and the new one. I think that's wrong, too, but maybe it's discussable. Maybe some preference setting could decide what the user likes to see/find: Only current content, or also recorded old content.

I made yet another test: Replacing a letter in the middle of a word (e.g. in "sam" replace the "a" with "i", creating "sim"): Now search neither finds the old "sam", nor the new "sim"! That just looks wrong to me (but it might be a different issue, even when originating from the same root).

Regarding the lack of CC:s: I guess the majority of people does not use "record changes", just as a majority of users does not care to report issues.
Comment 11 Mike Kaganski 2024-01-18 08:22:26 UTC 
(In reply to Ulrich Windl from comment #10)
> Regarding the lack of CC:s: I guess the majority of people does not use
> "record changes", just as a majority of users does not care to report issues.

This is a common misconception. Any real problem collects tens of duplicates; so please don't bring this idea to defend.

Please file search problems separately. Thank you.
Comment 12 Mike Kaganski 2024-01-18 09:36:45 UTC 
(In reply to Ulrich Windl from comment #10)
> Regarding the lack of CC:s: I guess the majority of people does not use
> "record changes", just as a majority of users does not care to report issues.

FTR: tdf#109272 (an issue created a bit *later* than this one; also discussing *change tracking*; also discussing cursor behavior when deleting ... - so very similar) has *three* duplicates, and 8 people in CC list (4 of them are users, not devs / QA). So again: the actual problems find their way to the Bugzilla, and their dupe / CC count clearly indicates their importance.