Description: If an existing ODS file with cell comments is saved in FODS format most of the time all or some of the cell comments will be lost. Steps to Reproduce: 1.Create ODS file with multiple cell comments 2.Save ODS file 3.Save as FODS file 4.Reload FODS and check for lost cell comments Actual Results: In many cases, some or all of the cell comments will be lost. Expected Results: Expected cell comments to be maintained Reproducible: Sometimes User Profile Reset: Yes Additional Info: User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:54.0) Gecko/20100101 Firefox/54.0
Created attachment 133723 [details] Spreadsheet with two cells with comments I have added a test case to demonstrate the issue.
Reproducible with: Version: 5.2.7.1 Build ID: bf0fa7b86c7c0592941ede29fca6fafff642a948 CPU Threads: 4; OS Version: Windows 6.2; UI Render: GL; Locale: es-ES (es_ES); Calc: group But works fine with: Version: 5.3.3.2 (x64) Build ID: 3d9a8b4b4e538a85e0782bd6c2d430bafe583448 CPU Threads: 4; OS Version: Windows 6.19; UI Render: GL; Layout Engine: new; Locale: es-ES (es_ES); Calc: group Please update you LibreOffice version as 5.2 is EOL there won't be new patches in it.
I can still reproduce the issue with 5.3.3.2 on Linux. Perhaps it is my setup.
Please try resetting the user profile, sometimes solves strange issues. https://wiki.documentfoundation.org/UserProfile Usually it's enough renaming/deleting the file "user/registrymodifications.xcu", it affects all the options in Menu/Tools/Options, and the files "user/basic/dialog.xlc" and "scrip.xlc" are overwritten, additionally custom colors in "user/config/standard.soc" are lost.
The issue is my how to reproduce is wrong. Try this: (1) Open the attached test case (2) Save file in FODS format (3) Close spreadsheet (4) Reopen file in FODS format. You should see the comments are missing. I've tried this on two different Debian based Linux distributions. Assuming that this is now reproducible, do I need to open a new bug as the original write-up is invalid?
Repro with: Version: 5.5.0.0.alpha0+ Build ID: 076ed447f694239d5c67adee528ea6e471d909ff CPU threads: 4; OS: Windows 6.19; UI render: default; TinderBox: Win-x86@42, Branch:master, Time: 2017-06-09_23:54:20 Locale: nl-NL (nl_NL); Calc: CL
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
cannot reproduce with Version: 5.3.7.2 Build ID: 6b8ed514a9f8b44d37a1b96673cbbdd077e24059 CPU Threads: 8; OS Version: Linux 4.14; UI Render: default; VCL: kde4; Layout Engine: new; Locale: nl-BE (en_US.UTF-8); Calc: group Version: 5.4.8.0.0+ Build ID: cc68977f1be22ac0f4a15eb37e05ccba13a7a554 CPU threads: 8; OS: Linux 4.14; UI render: default; VCL: kde4; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:libreoffice-5-4, Time: 2018-05-12_11:32:19 Locale: nl-BE (en_US.UTF-8); Calc: group Version: 6.2.0.0.alpha0+ Build ID: 7d521a85858bacdb7b5db359036ccf6f01b709c3 CPU threads: 8; OS: Linux 4.14; UI render: default; VCL: kde4; Locale: nl-BE (en_US.UTF-8); Calc: group threade
The problem still occurs for me. Version: 5.4.7.2 Build ID: c838ef25c16710f8838b1faec480ebba495259d0 CPU threads: 4; OS: Linux 4.4; UI render: default; VCL: kde4; Locale: en-US (en_US.UTF-8); Calc: group The steps to reproduce this issue must be very precise. 1) Load LibreOffice 2) Load the testcase file. 3) Do *not* save the file in the ODS format first. 4) *Do* save the file in the FODS format. 5) Close the file. 6) Open the FODS file. In my testing today, I find that saving the file first in the ODS format will cause the comments to be stored in the FODS *but* if the FODS file is further modified and saved the comments will be lost. The problem also appears to be reproducible in Version: 6.0.4.2 Build ID: 9b0d9b32d5dcda91d2f1a96dc04c645c450872bf CPU threads: 4; OS: Linux 4.4; UI render: default; VCL: kde4; Locale: en-US (en_US.UTF-8); Calc: group [it's unfortunate that my comment #1 does not have the correct steps to reproduce ... these are in comment #5]
following the steps in comment9 i reproduce the steps Version: 6.2.0.0.alpha0+ Build ID: b292a27698e85fd9d60c03613c3b0c67835c4dc1 CPU threads: 8; OS: Linux 4.14; UI render: default; VCL: kde4; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2018-06-07_02:03:56 Locale: nl-BE (en_US.UTF-8); Calc: group threaded
following the steps in comment9 i reproduce the steps in comment10 i mean following the steps in comment9 i can reproduce the problem
Dear John Carlson, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Using the "very precise" instructions in Comment #9, the problem still occurs using: Version: 6.2.4.2 Build ID: 2412653d852ce75f65fbfa83fb7e7b669a126d64 CPU threads: 4; OS: Linux 4.4; UI render: default; VCL: kde4; Locale: en-US (en_US.UTF-8); UI-Language: en-US Calc: threaded I *thought* the first time I tried it that it worked, but it has failed consistently since then (this includes restarting the program multiple times).
I can **NOT** reproduce the issue in Version 4.0.0.1 (Build ID: 527dba6f6e0cfbbc71bd6e7b88a52699bb48799).
repro Version: 4.2.0.0.alpha1+ Build ID: fc8f44e82de4ebdd50ac5fbb9207cd1a59a927e3
note: unable to bisect with bibisect-42max,lots of skipped commits
I can reproduce the problem always with the following software: Version: 6.0.7.3
Bibisected with Linux 42max to range https://git.libreoffice.org/core/+log/eb24baec8cc465218ca34302c2ddd2a24e023414..9fd0abe9abfe37cb1591e1db794e0c921d95b172 It was helpful to use this trick: https://wiki.documentfoundation.org/QA/Bibisect#Unable_to_start_soffice So I did: while (git clean -f -X && git bisect skip && ! opt/program/soffice ~/Downloads/test.ods); do : ; done whenever it refused to launch.
Seems similar to bug 117671.
I have encountered similar issues recently. The problem to me seems to be with editing the content of cells in the FODS file with some comments hidden, and then saving it. Saving the changes removes the hidden comments. The comments are not affected when they are not saved in hidden state (i.e. shown). This is actually a workaround which I have been forced to use, but worked for me (i.e. make all the comments shown, and arrange them so the data is not covered by them). I am running the following version on Debian testing: Version: 7.0.4.2 Build ID: 00(Build:2) CPU threads: 12; OS: Linux 5.10; UI render: default; VCL: gtk3 Locale: en-GB (en_GB.UTF-8); UI: en-GB Debian package version: 1:7.0.4-3 Calc: threaded Steps to reproduce: 1. Create new Calc file. 2. Enter 42 in cell A1. 3. add comment "Blabla" to cell B1. 4. Save spreadsheet in .fods format. 5. Reload the spreadsheet using File > Reload, and verify the comment is still there. 6. Enter 13 in cell C1. 7. Save the spreadsheet. 8. Reload the spreadsheet using File > Reload, and verify the comment is missing.
*** Bug 117671 has been marked as a duplicate of this bug. ***
Important comment from Timur in duplicate bug 117671: > Repro [...] if attached file just saved as, without looking at comments. > But, if comments hovered on and read, saved OK and no repro. This matches what Daniel says in Comment 20. So, updated steps could be: 1. Open attachment 133723 [details] 2. Hover over cell A1 to show comment (bot don't do it for cell A2) 3. File > Save as > fods 4. File > Reload Result: comment in cell A2 gone. Also from duplicate, Buovjaga suspects commit 5b483ed15d70bdc34b9520632ee569db0e6c4f9d by Kohei. Reproduced in recent master build: Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 23bd3bd10e74b0c23c2654d02d7d830e7693adac CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded
I can still reproduce this on latest master: Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 95e6f942b3fa5c6f3e5473ac474a4702ab815502 CPU threads: 4; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: zh-CN (zh_CN.UTF-8); UI: zh-CN Calc: threaded
The bibisected range in comment 18 seems to be not correct, because I can reproduce with commit eb24baec8cc465218ca34302c2ddd2a24e023414 (i.e., the first "good" commit as identified by the bibisect). I have re-run the bibisect using the linux-42max repo, and have identified the following range: https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=ae88290..eb24bae Trying to bisect...
Good in ae88290 but bad in 759bdbb. Bug introduced in: commit 759bdbbc348d320994813a9de1a7927b795580a3 Author: Laurent Godard <lgodard.libre@laposte.net> Date: Wed Sep 11 09:06:24 2013 +0200 Re-implement cell note storage using mdds::multi_type_vector. Adding Laurent Godard to cc: would you please take a look? However, it seems that Laurent Godard's last commit to libreoffice is in year 2015, so I am also adding Kohei Yoshida to CC.