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: 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
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
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. 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.
*** This bug has been marked as a duplicate of bug 135260 ***