Description: Already 2 undo steps created on file open Steps to Reproduce: 1. Open the attached file 2. Look at the undo steps in the toolbar Actual Results: 2 undo steps Expected Results: No undo steps Reproducible: Always User Profile Reset: No Additional Info: Found in 7.0 and in Versie: 4.4.7.2 Build ID: f3153a8b245191196a4b6b9abd1d0da16eead600 Locale: nl_NL
Created attachment 160551 [details] Example file
I was able to reproduce this under my version with the attached file and also with creating my own file. Steps to Reproduce: 1.Open a new writer file 2.Click in the menu bar on Format and then on Page 3.Select Columns 4.Set settings to 2 columns (see screenshot) 5.Apply those setting and close the page style window 6.Click Ctrl + F12 to create a new table 7.Enter at least 103 in rows 8.Insert the table 9.Safe the file 10.Close it 11.Open it Result: There are 2 undo steps for deleting frame style after opening. Triggering them doesn’t do anything. But redo after that really deletes the frame style. Expected Result: No undo steps after reopening. Reproducible: Always The bug appears after the page is split into two columns and entering a table with enough rows to let the table reach onto the second column of the second page. It probably can be triggered with other content too. So far, I could only reproduce it with a table. But I found a few ways that don’t trigger the bug. The bug doesn’t appear: • When the table doesn’t reach to the second column of the second page • When using text and line breaks to reach the second column of the second page • When splitting the page into 3 columns Additional Information: Version: 6.3.6.2 (x64) Build ID: 2196df99b074d8a661f4036fca8fa0cbfa33a497 CPU threads: 8; OS: Windows 10.0; UI render: GL; VCL: win; Locale: en-US (de_DE); UI-Language: en-US Calc: threaded
Created attachment 160554 [details] Columns settings
I was unable to reproduce the bug on the described Alpha version Version: 7.0.0.0.alpha1 (x64) Build ID: 6a03b2a54143a9bc0c6d4c7f1... CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win; Locale: en-NZ (en_NZ); UI: en-US Calc: threaded I was also unable to reproduce the bug in the stable version Version: 6.3.6.2 (x64) Build ID: 2196df99b074d8a661f4036fca8fa0cbfa33a497 CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; Locale: en-NZ (en_NZ); UI-Language: en-US Calc: threaded I attempted to replicate this bug over 10 times to no avail. If I were able to replicate the issue and had time available, I’d like to run the following tests: · Try to move the purple image to a different paragraph to see if the same behaviour occurs · After getting garbled text, try move the image back to its original location to see if the bug reverts · Resize the purple image before moving it to the affected location · Replace the image with a different image altogether and repeat the drag and drop · Insert another image and try to select both images and repeat the drag and drop · Repeat the test by moving a table or text box instead of an image · Change the text wrapping settings in the source and target paragraphs · Change the font of the document and reattempt the test · Adjust the document margins and retry the test · Attempt to replicate the bug in a different document · Open the file in Word (or copy and past the contents into Word) and attempt to replicate the bug These tests would help me to understand if the bug is related to the image being moved, the size/shape of the image, the formatting of the document, the contents of the document, and the application itself (vs a competitor)
(In reply to Mike Clarke from comment #4) > I was unable to reproduce the bug on the described Alpha version > > Version: 7.0.0.0.alpha1 (x64) > Build ID: 6a03b2a54143a9bc0c6d4c7f1... > CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: > win; > Locale: en-NZ (en_NZ); UI: en-US > Calc: threaded > > I was also unable to reproduce the bug in the stable version > > Version: 6.3.6.2 (x64) > Build ID: 2196df99b074d8a661f4036fca8fa0cbfa33a497 > CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; > Locale: en-NZ (en_NZ); UI-Language: en-US > Calc: threaded > > > I attempted to replicate this bug over 10 times to no avail. > > If I were able to replicate the issue and had time available, I’d like to > run the following tests: > > · Try to move the purple image to a different paragraph to see if the same > behaviour occurs > · After getting garbled text, try move the image back to its original > location to see if the bug reverts > · Resize the purple image before moving it to the affected location > · Replace the image with a different image altogether and repeat the drag > and drop > · Insert another image and try to select both images and repeat the drag and > drop > · Repeat the test by moving a table or text box instead of an image > · Change the text wrapping settings in the source and target paragraphs > · Change the font of the document and reattempt the test > · Adjust the document margins and retry the test > · Attempt to replicate the bug in a different document > · Open the file in Word (or copy and past the contents into Word) and > attempt to replicate the bug > > These tests would help me to understand if the bug is related to the image > being moved, the size/shape of the image, the formatting of the document, > the contents of the document, and the application itself (vs a competitor) Gah sorry, I meant to post this against 132265 (I was reviewing another bug at the same time) - apologies for the confusion
No repro 7.1+. Do not call this normal, if minor or trivial.