Description: Table pasted with Special paste RTF still present after undo Steps to Reproduce: 1. Open attachment 177053 [details] 2. CTRL+A 3. CTRL+C 4. CTRL+N 5. CTRL+SHIFT+V RTF 6. CTRL+Z Actual Results: Table still present after undo Expected Results: Empty page Reproducible: Always User Profile Reset: No Additional Info: Found in Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community Build ID: b9c159361abd79862b30412c433fb355d63299e2 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 and in Versie: 4.4.7.2 Build ID: f3153a8b245191196a4b6b9abd1d0da16eead600 Locale: nl_NL not in Version: 4.3.7.2 Build ID: 8a35821d8636a03b8bf4e15b48f59794652c68ba
More or less REPRODUCIBLE with reporter'ssample documentand Installation of Version 7.2.4.1 (x64) / LibreOffice Build 27d75539669ac387bb498e35313b970b7fe9c4f9 CPU threads: 12; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win; Locale: de-DE (de_DE); UI: de-DE; Calc: threaded; Elementary Theme; My normal User Profile a) I was also able to reproduce the effect with an own table. b) It's not "the table" what remains after <ctrl+z>. But it's something looking like a table, but you can't enter it. c) and it's not the complete table structure which remains- only the final table looking area from step 6 result. c1)And that area is something strange: it looks like a table, but you can't enter it after step 6 ... d) The problem is not a simple <ctrl+z> problem. You can't select and delete that area after step 6. It's a phantom ;-) e) If you search document from step 6 for "Платником" from most bottom cell (Table 10 A1) you will find that cell in document from after step 6. but the table looking area below seems to be completely new?
bisected to 9b74e669387c27a6643e9df26351f3ffdfc98921 is the first bad commit commit 9b74e669387c27a6643e9df26351f3ffdfc98921 Author: Norbert Thiebaud <nthiebaud@gmail.com> Date: Fri May 15 15:25:28 2015 -0500 source fa39e7970496537258eaad1f5351db2d675225b6 https://gerrit.libreoffice.org/c/core/+/14157
I would argue that this is indeed a bug, but it's not a regression. For one, this only "worked" for a short period of time, commit fa39e7970496537258eaad1f5351db2d675225b6 was a fix for bug 72486, which was itself a regression, so this only seemed to work after the initial work for select-all vs tables at doc start and that commit. For another, here are steps to reproduce this before the above commit: 1) Take e.g. linux-50max.git, check out f9d087f66b13035ff036ec04cf650f468227af32, i.e. the commit before core.git fa39e7970496537258eaad1f5351db2d675225b6. 2) Before you do ctrl-a (step 2 above), press enter to create an empty paragraph before the table, then press the down arrow to enter to the Table11:A1. 3) Then continue with the same steps: some unwanted layout frames will still present after undo, even before core.git fa39e7970496537258eaad1f5351db2d675225b6. So yes, this is a bug, it is worth fixing, but it's not a regression from the above commit, I would say. Adjusting keywords accordingly. I looked at the actual problem a bit, but it's tricky, somehow it's around how the undo for SwXText::convertToTable() works on an already existing document, so RTF import and ODF paste is not affected, just RTF paste. Would need more time to find out what's going on there.