Bug 142539 - table corrupt after insert row above
Summary: table corrupt after insert row above
Status: RESOLVED DUPLICATE of bug 131025
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected) release
Hardware: All All
: high normal
Assignee: Not Assigned
Keywords: bibisected, bisected, dataLoss, regression
Depends on:
Blocks: Writer-Tables
  Show dependency treegraph
Reported: 2021-05-28 11:48 UTC by Evgen
Modified: 2021-10-21 17:58 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:

test file for bug demostration and screanshots (45.52 KB, application/x-zip-compressed)
2021-05-28 11:48 UTC, Evgen

Note You need to log in before you can comment on or make changes to this bug.
Description Evgen 2021-05-28 11:48:15 UTC
Created attachment 172403 [details]
test file for bug demostration and screanshots

1. Open Test.odt Look like  1.jpg
2. move cursor to second table raw and click right mouse button
   select add raw above. Look like  2.jpg
3. Save file as Test_1.odt and close Writer
4. In LibreOffice recent document preview you will see something like 3.jpg
5. If you open file Test_1.odt then you will see 4.jpg with corrupted text
Comment 1 raal 2021-05-29 15:39:55 UTC
Repro with 7.2, but not with 4.1. regression.
Comment 2 raal 2021-05-29 16:09:17 UTC
This seems to have begun at the below commit.
Adding Cc: to Maxim Monastirsky ; Could you possibly take a look at this one?
linux-64-6.5$ 131b23e24d6a2731df74afa57acffe61ab1ee50c is the first bad commit
commit 131b23e24d6a2731df74afa57acffe61ab1ee50c
Author: Jenkins Build User <tdf@pollux.tdf>
Date:   Thu Feb 27 19:26:45 2020 +0100

    source 59ace23c367f83491a37e844d16f7d716eff6346

  tdf#101710 Fix invalid style:data-style-name attribute
Comment 3 Justin L 2021-10-20 08:49:18 UTC
This is almost certainly just an exposure of existing 6.0 bug 131025.

*** This bug has been marked as a duplicate of bug 131025 ***
Comment 4 Justin L 2021-10-20 13:05:47 UTC
In English locale I can't reproduce this from scratch. If I create a document like this, it uses "General" as the format it copies instead of "Standard".  It seems to be language dependent. Russian (as in OPs document) uses Standard instead of General, and in that case I can reproduce this. As noted in bug 131025 comment 34, General does not seem to be affected.

Most of the styles have text formatting (@) for column 1 and row 1 with General/Standard format for the rest. So that explains why SOME cells are not affected.
@ @ @ @
@ G G G
@ G G G
Comment 5 Justin L 2021-10-21 17:58:01 UTC
There seems to be some kind of import discrepancy. If I unzip the ODT and edit styles.xml's number:number-style and comment out
<!-- number:language="ru" number:country="RU">-->
then the file loads as expected.

Similarly, if I add that to my English locale example (in which I couldn't reproduce the problem from scratch), then its text turns into zeros as well.