Bug 135260 - Backspace has only effect on one character after rejecting all changes
Summary: Backspace has only effect on one character after rejecting all changes
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.4.6.2 release
Hardware: All All
: high critical
Assignee: Michael Stahl (allotropia)
URL:
Whiteboard: target:7.1.0 target:7.0.3
Keywords: bibisected, bisected, regression
: 136504 136833 137241 138008 138105 (view as bug list)
Depends on:
Blocks: Track-Changes redlinehide-regressions
  Show dependency treegraph
 
Reported: 2020-07-29 09:11 UTC by Telesto
Modified: 2020-11-19 11:09 UTC (History)
9 users (show)

See Also:
Crash report or crash signature:


Attachments
Example file (60.96 KB, application/vnd.oasis.opendocument.text)
2020-07-29 09:11 UTC, Telesto
Details
Screencast (1.79 MB, video/mp4)
2020-07-29 09:12 UTC, Telesto
Details
Very short sample document (11.00 KB, application/vnd.oasis.opendocument.text)
2020-10-09 00:41 UTC, Luke Kendall
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2020-07-29 09:11:02 UTC
Description:
Backspace has only effect on one character after rejecting all changes

Steps to Reproduce:
1. Open the attached file
2. Select for example mathématicien
3. Right click -> Character style -> Emphasis
4. Edit -> Track changes -> Mange -> Reject all
5. Place cursor after '300' and press and hold backspace

Actual Results:
Only one zero gets marked as a change.. backspace stops doing something

Expected Results:
Should work


Reproducible: Always


User Profile Reset: No



Additional Info:
Version: 7.1.0.0.alpha0+ (x64)
Build ID: <buildversion>
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win
Locale: nl-NL (nl_NL); UI: en-US
Calc: CL
Comment 1 Telesto 2020-07-29 09:11:26 UTC
Created attachment 163726 [details]
Example file
Comment 2 Telesto 2020-07-29 09:12:22 UTC
Created attachment 163727 [details]
Screencast
Comment 3 Telesto 2020-07-29 09:15:08 UTC
No repro with
Version: 6.3.0.0.beta1+ (x86)
Build ID: 5cfac16dbd4af456a7fb6d52c8953c69a72ba2ba
CPU threads: 4; OS: Windows 6.3; UI render: default; VCL: win; 
Locale: nl-NL (nl_NL); UI-Language: en-US
Calc: CL
Comment 4 Attila Baraksó (NISZ) 2020-08-19 11:58:18 UTC
Reproduced in:

Version: 7.1.0.0.alpha0+
Build ID: ce6c6a5ad6c9dde09bb0bb0c51e16d828cfe0ef7
CPU threads: 6; OS: Linux 5.4; UI render: default; VCL: gtk3
Locale: en-GB (hu_HU.UTF-8); UI: en-US
Calc: threaded
Comment 5 Attila Baraksó (NISZ) 2020-08-19 12:14:01 UTC
Bibisected using linux-64-7.1 to:
URL: https://cgit.freedesktop.org/libreoffice/core/commit/?id=398ba26077f9029bdf6f7378bfc9ce8376b6f02d
author: Michael Stahl <Michael.Stahl@cib.de>
committer: Michael Stahl <Michael.Stahl@cib.de>
summary: tdf#127635 sw_redlinehide: put point at the end of deletion

Adding CC: Michael Stahl
Comment 6 Telesto 2020-09-17 11:49:14 UTC
*** Bug 136833 has been marked as a duplicate of this bug. ***
Comment 7 Attila Baraksó (NISZ) 2020-09-22 14:01:40 UTC
*** Bug 136504 has been marked as a duplicate of this bug. ***
Comment 8 Lars Jødal 2020-10-07 07:17:00 UTC
*** Bug 137241 has been marked as a duplicate of this bug. ***
Comment 9 Lars Jødal 2020-10-07 07:18:23 UTC
I also see the bug, which is not tied to the specific document but generally to the track-changes feature.

General steps to reproduce:
1. Open a Writer document.
2. Write some text without track-changes being turned on.
3. Turn on track-changes AND visibility of track-changes.
4. Begin deleting text with backspace.

Actual results:
One character is deleted and marked as deleted, but the cursor does not not change position. As a result of the cursor standing still, pressing backspace more than one time will only delete the same character over and over again.

Expected results:
The cursor should move back with backspace deletion, allowing deletion of the previous character if backspace is pressed once again.

Further comments:
If "show track-changes" is turned off, characters are deleted as expected.

I appears that the resolution to bug #127635 caused this regression.
Comment 10 Luke Kendall 2020-10-09 00:41:05 UTC
Created attachment 166212 [details]
Very short sample document

Here's another short sample document.
Note that in addition to deletion stopping after a single backspace, the deletion is also not undone by Undo.

Steps to reproduce:
1. Open the sample document.
2. Ensure Track Changes, Record, and Show are enabled
3. Position the cursor after the “s” in “eyes”, on the line with the comment.
4. Backspace as many times as you like
5. Only the letter 's' is deleted.
6. Selecting Undo does not undelete the deletion.

(You can work around that problem by selecting the change and rejecting it.)
Comment 11 Lars Jødal 2020-10-09 05:25:45 UTC
(In reply to Luke Kendall from comment #10)
> Note that in addition to deletion stopping after a single backspace, the
> deletion is also not undone by Undo.

My experience is that Undo works fine - but if I have pressed backspace e.g. 3 times, then I must also do Undo 3 times before I see a visible effect. I consider that a logical behaviour of Undo.

Tested with LO 7.0.2.2, both on attachment 166212 [details] and on a newly created document (writing something, turning on track changes & show track changes, then beginning the test).
Comment 12 Luke Kendall 2020-10-09 05:31:51 UTC
You're perfectly correct about the Undo.  (I think I failed to remember how many times I'd backspaced.)
Although one might argue that deleting a deleted character is a no-op, I can see it would get complicated if there was a deletion of some deleted characters and some undeleted characters, so I'm not arguing!
Comment 13 Luke Kendall 2020-10-09 05:34:42 UTC
By the way, I think the bug is super simple to reproduce.
With Record and Show changes on, you can place the cursor anywhere in a document where changes are tracked (e.g. not in a comment), and backspace and Writer will only delete a single character.

(Using Delete to delete a character and move to the right however does work.)
Comment 14 Commit Notification 2020-10-14 13:26:41 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/be4616d6b49b8c9cf1a90b212b24ead3dabcab6c

tdf#135260 sw_redlinehide: fix insert-with-delete differently

It will be available in 7.1.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.
Comment 15 Michael Stahl (allotropia) 2020-10-14 13:28:07 UTC
fixed on master
Comment 16 Luke Kendall 2020-10-14 13:44:16 UTC
(In reply to Luke Kendall from comment #13)
> By the way, I think the bug is super simple to reproduce.
> With Record and Show changes on, you can place the cursor anywhere in a
> document where changes are tracked (e.g. not in a comment), and backspace
> and Writer will only delete a single character.
> 
> (Using Delete to delete a character and move to the right however does work.)

I should have added to "anywhere in a document where changes are tracked" the exception "unless the text is marked as an Addition.
Comment 17 Commit Notification 2020-10-14 19:40:27 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "libreoffice-7-0":

https://git.libreoffice.org/core/commit/10c638e520096a0cc282d91ac2a447509f674a6f

tdf#135260 sw_redlinehide: fix insert-with-delete differently

It will be available in 7.0.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.
Comment 18 Lars Jødal 2020-10-15 06:38:43 UTC
Tested with 7.0.3.0.0.+ and 7.1.0.0.alpha+ master build. I can confirm that the fix has resolved the bug.

Any chance of getting the fix into the 6.4.x line (for which it was a regression by the 6.4.6 release)? Or is it too late and not worth it, as that line has planned end-of-life less than two months from now?

Version: 7.0.3.0.0+ (x64)
Build ID: ba5584a3ce86c2db52e2e4a4b91254741b2616ec
CPU threads: 4; OS: Windows 10.0 Build 18362; UI render: Skia/Raster; VCL: win
Locale: da-DK (da_DK); UI: da-DK
Calc: threaded

Version: 7.1.0.0.alpha0+ (x64)
Build ID: c064766901722082df0d759c95434c1460fcdba5
CPU threads: 4; OS: Windows 10.0 Build 18362; UI render: Skia/Raster; VCL: win
Locale: da-DK (da_DK); UI: da-DK
Calc: threaded
Comment 19 Telesto 2020-10-15 08:39:07 UTC
(In reply to Lars Jødal from comment #18)
> Any chance of getting the fix into the 6.4.x line (for which it was a
> regression by the 6.4.6 release)? Or is it too late and not worth it, as
> that line has planned end-of-life less than two months from now?

Ideally - in a perfect world - it would be pushed into 6.4. However looking at the schedule, its little to late based for 6.4.7.2 with fixed schedule.

And there a no new releases planned. So we move on to 7.0. The LTS variant of 6.4 is available at eco-system partners, which will likely include the fix here. If 6.4 being preferred for some reason.
Comment 20 Commit Notification 2020-10-16 11:27:36 UTC
Xisco Fauli committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/c143ad222a3c4c8d86699e1b3f20d3a5262da1e2

tdf#135260: sw_uiwriter: Add unittest

It will be available in 7.1.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.
Comment 21 Xisco Faulí 2020-10-30 11:09:06 UTC
(In reply to Lars Jødal from comment #18)
> Tested with 7.0.3.0.0.+ and 7.1.0.0.alpha+ master build. I can confirm that
> the fix has resolved the bug.
> 
> Any chance of getting the fix into the 6.4.x line (for which it was a
> regression by the 6.4.6 release)? Or is it too late and not worth it, as
> that line has planned end-of-life less than two months from now?
> 
> Version: 7.0.3.0.0+ (x64)
> Build ID: ba5584a3ce86c2db52e2e4a4b91254741b2616ec
> CPU threads: 4; OS: Windows 10.0 Build 18362; UI render: Skia/Raster; VCL:
> win
> Locale: da-DK (da_DK); UI: da-DK
> Calc: threaded
> 
> Version: 7.1.0.0.alpha0+ (x64)
> Build ID: c064766901722082df0d759c95434c1460fcdba5
> CPU threads: 4; OS: Windows 10.0 Build 18362; UI render: Skia/Raster; VCL:
> win
> Locale: da-DK (da_DK); UI: da-DK
> Calc: threaded

Setting to VERIFIED. Unittest was added too

@Michael Stahl, thanks for fixing this issue!!
Comment 22 Ming Hua 2020-11-05 11:18:36 UTC
*** Bug 138008 has been marked as a duplicate of this bug. ***
Comment 23 Victor 2020-11-07 17:02:08 UTC
7.0.3 just hit the repros of my distribution. Thank you @Michael Stahl for solving this issue
Comment 24 Ming Hua 2020-11-10 05:59:48 UTC
*** Bug 138105 has been marked as a duplicate of this bug. ***
Comment 25 Dave Lovelace 2020-11-18 01:01:43 UTC
Something else is going on here.  OK, I'm still running 6.4.6.2 (x64).  But I've been running it for quite a while.  And I was editing a document which I've been using for, literally, years now, with Track Changes on all the while.  And now, one minute backspace was working properly and the next minute it wasn't.

So the problem isn't simply that Track Changes is enabled.  SOMETHING else got turned on or off in the middle of my editing TODAY.

So there should be a workaround to change that setting, whatever it is.  I can't afford to turn Track Changes off, but I also can't live with the present behavior.

I'm hesitant to just upgrade to 7.anything at this point.  Maybe I'll have to, but a working program shouldn't just stop working in the middle of an edit!
Comment 26 Aron Budea 2020-11-18 03:29:21 UTC
Dave, there isn't much point in testing what's up in 6.4.6. The bug might occur with different steps as well, and it may as well be fixed by the same fix, you won't know unless you test with the version that contains fix. You could always install the latest 7.0 version separately:
https://wiki.documentfoundation.org/Installing_in_parallel
Comment 27 Lars Jødal 2020-11-18 07:54:44 UTC
(In reply to Dave Lovelace from comment #25)
> I'm hesitant to just upgrade to 7.anything at this point.  Maybe I'll have
> to, but a working program shouldn't just stop working in the middle of an
> edit!
The bug is only seen when you are using backspace to delete inserted text, while there is no problem deleting text otherwise. Perhaps this difference makes it seem like it "just stop working"? Or perhaps you are seeing some behaviour not earlier covered. However, the 6.4.x line has had its last release and officially expires by the end of this month. https://wiki.documentfoundation.org/ReleasePlan

So as Aaron says, testing 6.4.6 (or 6.4.7) won't have much point. A fix was applied to the 7.0-line (unfortunately to late to make it to the 6.4.x-line). If that fix was not enough, it needs demonstration in the 7.0-line, and will only be fixed in the 7.0-line. It is too bad that this regression happened, but given that there will not be a 6.4.8 release, you have two choices: Take a step backward or take a step forward.

A step backward: The regression was introduced in 6.4.6 (as a side effect of the fix for bug 127635), so you could go back to 6.4.5. At the bottom of the official download page, there is a link to the archive of old versions.

A step forward: Upgrade to 7.0.3. It is already the fourth official release (counting 0, 1, 2, 3), so it is not that much of a newcomer, even if it is still the "fresh" version on the download page.