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.
Deleting something pretty hard; repro
Version: 184.108.40.206.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
everything still ok in
Build ID: 9d754a59154c40235c240bb0e7f47a2006fa85bd
CPU threads: 4; OS: Windows 6.3; UI render: default;
Locale: nl-NL (nl_NL); Calc: CL
Created attachment 166137 [details]
author Michael Stahl <Michael.Stahl@cib.de> 2020-06-19 16:32:19 +0200
committer Michael Stahl <firstname.lastname@example.org> 2020-06-19 20:50:58 +0200
commit 92dbbf840c1da7628bcdd9e8f67375efc2a2fa14 (patch)
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)
Adding CC: to Michael Stahl
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.
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.
The cursor should move back with backspace deletion, allowing deletion of the previous character if backspace is pressed once again.
If "show track-changes" is turned off, characters are deleted as expected.
I appears that the resolution to bug #127635 caused this regression.
*** This bug has been marked as a duplicate of bug 135260 ***