Bug 137241 - Unable to backspace over some text (track changes)
Summary: Unable to backspace over some text (track changes)
Status: RESOLVED DUPLICATE of bug 135260
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.4.4.2 release
Hardware: x86-64 (AMD64) All
: high major
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
Depends on:
Blocks: redlinehide-regressions
  Show dependency treegraph
 
Reported: 2020-10-04 13:58 UTC by Luke Kendall
Modified: 2020-11-19 11:09 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
Very short sample document (79.31 KB, application/vnd.oasis.opendocument.text)
2020-10-04 13:58 UTC, Luke Kendall
Details
Bibisect log (2.90 KB, text/plain)
2020-10-06 20:48 UTC, Telesto
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Luke Kendall 2020-10-04 13:58:29 UTC
Created attachment 166064 [details]
Very short sample document

While editing a document, with record and show changes enabled, I found after backspacing to delete a period left behind after copying some text elsewhere, that I could not backspace over it to the characters to its left. It was as if the deleted period formed a barrier.
I also found that although "Undo delete "."" appeared in the text to the right of the "Edit: Undo" menu, choosing to Undo had no effect, and that undo item stayed unchanged.

I have provided a vastly cut down document that for me shows the problem.

Steps to reproduce:

1. Position the cursor immediately to the right of the 2nd period after "valuable"
2. Attempt to backspace to travel left over the already deleted text and then to delete characters further to the left
3. The cursor will not move, characters can not be deleted by backspacing.
4. Note the Edit menu item for Undo says Undo: Delete "."
5. Attempt to undo that deletion: nothing happens.
Comment 1 Telesto 2020-10-04 15:33:04 UTC
Deleting something pretty hard; repro
Version: 7.1.0.0.alpha0+ (x64)
Build ID: 7f16cabf00daa30e9284d2fb2494bd341352c25e
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

everything still ok in
Version: 6.2.0.0.alpha0+
Build ID: 9d754a59154c40235c240bb0e7f47a2006fa85bd
CPU threads: 4; OS: Windows 6.3; UI render: default; 
Locale: nl-NL (nl_NL); Calc: CL
Comment 2 Telesto 2020-10-06 20:48:12 UTC
Created attachment 166137 [details]
Bibisect log

Bisected to:
author	Michael Stahl <Michael.Stahl@cib.de>	2020-06-19 16:32:19 +0200
committer	Michael Stahl <michael.stahl@cib.de>	2020-06-19 20:50:58 +0200
commit 92dbbf840c1da7628bcdd9e8f67375efc2a2fa14 (patch)
tree 2dcb2e1be891b27cd5619478678d9b6eba3fe464
parent 461e9f2ad21046526c6644136f0abda91b0e4798 (diff)
tdf#127635 sw_redlinehide: put point at the end of deletion
SwWrtShell::Insert() is called with a selection, so it first calls
DeleteAndJoin() to get rid of the selection.

With redlining enabled, this leaves the cursor as it was before, so if
the point was at the start it still is at the start, so the following
Insert will insert at the start of the selection.

But then AutoCorrect wants to do things and it uses TextFrameIndex and
ViewToModelPos and gets a result at the end of the delete redline,
while the cursor remains at the start of the delete redline.

Avoid this by swapping the selection after DeleteAndJoin() (and also
DeleteRange() for consistency) so that insertion happens at end of
redline (swap "above" DoWithBreaks because it creates temporary PaMs).

(regression from sw_redlinehide)

https://cgit.freedesktop.org/libreoffice/core/commit/?id=92dbbf840c1da7628bcdd9e8f67375efc2a2fa14
Comment 3 Telesto 2020-10-06 20:49:06 UTC
Adding CC: to Michael Stahl
Comment 4 Lars Jødal 2020-10-07 07:09:57 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 5 Lars Jødal 2020-10-07 07:17:00 UTC

*** This bug has been marked as a duplicate of bug 135260 ***