Bug 135209 - TABLE: Two columns of a table containing only zeros after saving as fodt, closing and re-opening (document specific?)
Summary: TABLE: Two columns of a table containing only zeros after saving as fodt, clo...
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.4.5.2 release
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Writer-Tables
  Show dependency treegraph
 
Reported: 2020-07-27 23:42 UTC by Christian
Modified: 2022-11-12 05:07 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments
File that I never used Zotero on (except having the addon installed) that has the 0 in the last column last row (40.55 KB, application/vnd.oasis.opendocument.text-flat-xml)
2020-07-27 23:43 UTC, Christian
Details
Copy of the file that the problem originally appeared on and can be reproduced on (74.35 KB, application/vnd.oasis.opendocument.text-flat-xml)
2020-07-27 23:44 UTC, Christian
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Christian 2020-07-27 23:42:03 UTC
Description:
Hello everyone.

I encountered the following and would like to seek assistance in analysis:

I did some work in a LibreOffice Writer 6.4.5.2 document, including a table. The table had some text and two references inserted by Zotero 5.0.88 from the Writer addon. I had the document open all day, saved it every now and then and at the end of the day I closed it. When I re-opened it the next day, I found the table containing a lot of zeros instead of my text. Now when I replace one of the zeros with text, save and re-open, the text is gone again and replaced again with a zero.

It is interesting that the first column is completely intact, the second column has two rows intact, one with citation and one without, one of the zeros in the broken rows in the second column is a reference to the other citation, and the third (last) column has only zeros. The rest of the document is okay.

I also noted that my formatting in the table (some rows had strike-through) got lost every time I inserted a citation. That's why I also reported this problem in the Zotero forums. However, the error is now reproducible even with Zotero closed and when not using any Zotero functionality (except leaving the existing citations where they are), so I would like to investigate if this is Writer related. I also have hints that a similar problem exists when Zotero is not used from a fresh document.

Where should I start here? I can provide the document, the error is reproducible, what is the preferred way to provide files?

I also began reproducing the problem with new documents. See "Steps to Reproduce" for what I found. It seems to be related to the layout.

I used the "flat" format (fodt). I used the "academic" layout for the table.

I am using Manjaro Linux with Gnome.

Please help me find the problem.

Christian

Steps to Reproduce:
1. Create new document. 
2. Create 3 column 6 row table without headings in academic layout.
3. Fill the table with random nonsense.
4. Save as fodt under any filename.
5. Close.
6. Re-open.

Actual Results:
The field in the last column, last row, is now a zero.

Expected Results:
The document should be the same as when I closed it.


Reproducible: Always


User Profile Reset: No


OpenGL enabled: Yes

Additional Info:
When using the default table layout, nothing is replaced.
Comment 1 Christian 2020-07-27 23:43:26 UTC
Created attachment 163659 [details]
File that I never used Zotero on (except having the addon installed) that has the 0 in the last column last row
Comment 2 Christian 2020-07-27 23:44:13 UTC
Created attachment 163660 [details]
Copy of the file that the problem originally appeared on and can be reproduced on
Comment 3 John Healey 2020-08-03 20:27:22 UTC
I have the same problem with version 6.3.6.2 (x64} on Windows 10. Zotero is not involved in my case.
Comment 4 Dieter 2020-08-15 15:53:04 UTC
I can't confirm with

Version: 7.0.0.3 (x64)
Build ID: 8061b3e9204bef6b321a21033174034a5e2ea88e
CPU threads: 4; OS: Windows 10.0 Build 19041; UI render: Skia/Raster; VCL: win
Locale: de-DE (de_DE); UI: en-GB
Calc: threaded

But it seems, that tably style "Academic" has been removed

So could you please try to reproduce it with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version. Change to RESOLVED WORKSFORME, if the problem went away.
Comment 5 Christian 2020-09-04 00:23:11 UTC
I can still reproduce the bug as described in 7.0.0.3. Also, I still have the "academic" style.
Comment 6 najmun1111 2020-11-04 04:33:23 UTC
I have the same problem.

To me, the text would not change to 0 if I use the default format, but changed to 0 if use table formatting.

The columns that turned to 0 are the 'Text Only' column and the 'Text with numbers in it' column. The  'Numerical value' and the first columns stay intact.
Comment 7 Dieter 2020-11-04 08:04:17 UTC
I confirm it with

Version: 7.0.3.1 (x64)
Build ID: d7547858d014d4cf69878db179d326fc3483e082
CPU threads: 4; OS: Windows 10.0 Build 19042; UI render: default; VCL: win
Locale: de-DE (de_DE); UI: de-DE
Calc: threaded
Comment 8 Dieter 2020-11-04 08:08:08 UTC
I've changed severity to major, because content gets lost.
Comment 9 QA Administrators 2022-11-05 03:35:57 UTC Comment hidden (obsolete)
Comment 10 Dieter 2022-11-07 06:18:12 UTC
I can still reproduce it with table from attachment 163660 [details], but not with a table created on my own.

Steps
1. Open attachment 163660 [details]
2. Copy table and paste in into a new document
3. Make sure, that table style is Academic
4. Insert some numbers into the last few cells
5. Save as .fodt and reload

Result:
Number in last cell is replaced with 0

Christian, are you still able to reproduce it with a new table?
=> NEEDINFO
Comment 11 Christian 2022-11-10 18:49:53 UTC
I can no longer reproduce the issue with a fresh file. I also cannot reproduce the issue with the attached file. I work on a fresh install of LibreOffice though.
Comment 12 Dieter 2022-11-10 20:23:10 UTC
(In reply to Christian from comment #11)
> I can no longer reproduce the issue with a fresh file. I also cannot
> reproduce the issue with the attached file. I work on a fresh install of
> LibreOffice though.

=> RESOLVED WORKSFORME