Created attachment 84702 [details] test document for reproducing the bug When comments contain German quote characters "„", "“", upon saving the document in OOXML format, part of the comment text may be lost. This bug can be reliably reproduced by means of the following steps: 1) open the attached file Test.docx in Libreoffice 2) add e.g. the text "(quotation marks)" at the end of the comment 3) save 4) exit LibreOffice 5) start LibreOffice again and open the file again The newly added comment text will have been lost. I have tested this for the following versions of LibreOffice, each of which has the bug: LibreOffice 3.5.4.2 Build-ID: 350m1(Build:2) Version 3.6.7.2 (Build ID: e183d5b) Version 4.0.5.2 (Build ID: 5464147a081647a250913f19c0715bca595af2f) Version: 4.1.0.4 (Build ID: 89ea49ddacd9aa532507cbf852f2bb22b1ace28)
modified summary notes and changed version to the earliest where the bug has been reproduced by reporter. @Norbert Bollow have you tried 4.1.1 released today? is it still affected?
I've just tried Version: 4.1.1.2 (Build ID: 7e4286b58adc75a14f6d83f53a03b6c11fa2903)... it is still affected.
Created attachment 84904 [details] test file saved under Windows tested with 4.0.4 and 4.1.0 final releases under Win7 64bit. I can't reproduce the bug... I can normally edit the comment and saving it without data loss when I reopen it. see my attached file. can you see my edits?
This is interesting. Attachment 84904 [details] opens ok for me (Debian GNU/Linux 7.1). Moreover I've tried to reproduce (again on Debian GNU/Linux 7.1) the exact same changes that were done to create attachment 84904 [details], with the result that those changes did not get saved correctly.
For an additional data point, I've just tried Ubuntu 13.04 which comes with LibreOffice 4.0.2.2 (Build ID: 400m0(Build:2)). My test case works correctly there (i.e. does not show the bug).
Another data point: On Sabayon Linux 13.08 with LibreOffice 4.1.0.4, Build ID: Sabayon Official Package, the bug occurs. So it is not Debian-specific.
I'm seeing what looks like the same bug, under Ubuntu, using LO 41.3. Has anyone had any luck fixing this bug? I've just lost a bunch of student paper comments, am feeling quite discouraged!
Created attachment 90482 [details] DOCX test file saved under various OS/LO versions. I am unable to confirm the behaviour described in this bug. Perhaps it is locale-specific (I am using en_AU.utf-8)? I opened the DOCX provided in comment #0 and re-saved it after editing the comment as suggested under Ubuntu 10.04 x86_64 running: - v3.3.0.4 OOO330m19 Build: 6 - v3.4.6.2 OOO340m1 Build: 602 - v3.5.7.2 Build ID: 3215f89-f603614-ab984f2-7348103-1225a5b - v3.6.7.2 Build ID: e183d5b - v4.0.6.2 Build ID: 2e2573268451a50806fcd60ae2d9fe01dd0ce24 - v4.1.3.2 Build ID: 70feb7d99726f064edab4605a8ab840c50ec57a I also did the same under Crunchbang 11 x86_64 running the same versions, except instead of v3.3.0.4 I used: - v3.3.4.1 OOO330m19 Build: 401 ... and again under MS Windows 7 (6.1.7601) running: - v4.1.2.2 Build ID: 281b75f427729060b6446ddb3777b32f957a8fb Only the two versions from the v3.3 series exhibited problems with comment loss, however as the included screenshots show, the <w:rPr> and <w:dstrike> tags appear to be mis-interpreted by these old versions, so this is likely a different issue. All other versions write the comment out as expected. I even tried making the same change as indicated in comment #3 but the results were the same (comment content maintained).
Oh, I just realised the Architecture is set to IA32 and all my GNU/Linux tests were AMD64. There is no indication in other comments whether the various linux flavours were 32bit or 64bit. It would be good if this could be clarified.
All of my tests have been with IA32 and with LANG=de_CH.UTF-8
(In reply to comment #10) > All of my tests have been with IA32 and with LANG=de_CH.UTF-8 Thanks for clarifying these two aspects Norbert. We need to get someone with an IA32 linux install to confirm / eliminate this aspect. I also forgot to mention that my version of Win7 is 64bit. :-(
(In reply to comment #11) Would it be helpful for me to repeat some of my tests with different locale settings and/or on a 64bit Debian install which I could set up for that purpose on a spare machine?
(In reply to comment #12) > Would it be helpful for me to repeat some of my tests with different locale > settings and/or on a 64bit Debian install which I could set up for that > purpose on a spare machine? If you can that would be great. At the moment only IA32 installs exhibit the problem, so if you can confirm that AMD64 installs of the same distributions do not at least we will then know this is a factor. I will see if I can perform some tests here as well using live DVDs for some IA32 systems. Not sure how successful that will be. I will try and do some locale testing as well, although I am even less confident doing this, but I am hoping it will be easy.
Norbert, I edited your provided DOCX under Window Maker Live 2013-06-05 i386 running: - v3.3.0.4 OOO330m19 Build: 6 - v3.4.6.2 OOO340m1 Build: 602 - v3.5.7.2 Build ID: 3215f89-f603614-ab984f2-7348103-1225a5b - v3.6.7.2 Build ID: e183d5b - v4.0.6.2 Build ID: 2e2573268451a50806fcd60ae2d9fe01dd0ce24 - v4.1.3.2 Build ID: 70feb7d99726f064edab4605a8ab840c50ec57a Again though the comment was preserved as expected in all cases after saving, exiting, and reopening the edited document. It would seem more likely that this is a locale-related issue.
Curiously, on my main desktop machine (32bit Debian 7.2) I can currently not reproduce the bug anymore although I'm still using the same version of LibreOffice (3.5.4.2 Build-ID: 350m1(Build:2)). I think this points to the bug being in a dynamically loaded library used by LibreOffice. I have in the meantime upgraded some packages, some of them to versions from deb-multimedia.org... I will try to narrow this down more. By contrast, I the bug still occurs on a fresh AMD64 Debian7.2 install which is a straightforward install of just the packages from CD1 (without using any online Debian mirror) to which I've manually added (with dpkg -i) all the .deb packages contained in LibreOffice_4.1.3_Linux_x86-64_deb.tar.gz In both cases there is no change to the observed behavior if I start the program manually from the command line with an explicit LANG=C environment variable setting.
Created attachment 90872 [details] contents of ~/.config/libreoffice to reproduce the bug
(In reply to comment #15) It turns out that the difference between the behavior between the two computers seems to be due to different contents of ~/.config/libreoffice ... If there is no ~/.config/libreoffice the bug does not occur. I have attached a tarball of a ~/.config/libreoffice which allows to reproduce the bug (tested on 32bit Debian 7.2 with LibreOffice 3.5.4.2 Build-ID: 350m1(Build:2)).
Norbert, I re-tested your provided DOCX, this time with the v3 profile you also provided, under Ubuntu 10.04 x86_64 using: - v3.4.6.2 OOO340m1 Build: 602 - v3.5.7.2 Build ID: 3215f89-f603614-ab984f2-7348103-1225a5b - v3.6.7.2 Build ID: e183d5b Again though the result was the same (no problem editing and making changes to the comment and having those changes saved as expected). This combined with this statement from comment #17 suggests it may have been a user profile issue: > If there is no ~/.config/libreoffice the bug does not occur. The user profile will be re-created if one is not found at start-up. It sounds like the original profile is exhibiting a problem (which is a relatively common occurrence). Removing the user profile fixes the issue (which is the recommended procedure). I think you could RESOLVE this bug as WORKSFORME.
(In reply to comment #18) Having lost significant work (in the form of comment texts) due to this bug, I *strongly* *disagree* with the idea that this could be simply resolved as "WORKSFORME". Loss of text is something that really must not be allowed to happen under any circumstances. I'll set up an Ubuntu 10.04 x86_64 test system with en_AU.utf-8 locale to see if I can find a way to reproduce the bug in that kind of environment.
(In reply to comment #18) Owen, have you tested with "Save" or with "Save as..."? It seems that only "Save" triggers the bug. (This may in fact be a strong hint that may help in finding the bug in the codebase... how does it happen that the textual content of the file that is generated differs between the results of "Save" and "Save as..."!?) In any case, I have now done a test on an OS platform similar to what you're using, and found that the bug does occur in that test setup. Specifically I've proceeded as follows: * Downloaded ubuntu-10.04.4-server-amd64.iso and installed from there onto a freshly formatted partition without including any other partitions, in particular no /home partition with pre-existing data... I used the “server” .iso because I didn't fidn a desktop .iso, which made the next two steps necessary * Locale choices: English language, country=Australia * sudo apt-get install swfdec-mozilla * sudo apt-get install gnome-desktop * Rebooted * Downloaded LibreOffice_4.1.4_Linux_x86-64_deb.tar.gz and installed the *.deb files by means of "dpkg -i". * Downloaded the Test.docx and ~/,config/libreoffice that I have provided here. * Unpacked the ~/,config/libreoffice tarball into that place. * Started LibreOffice from the Gnome menu * Opened Test.docx * added text at the end of the comment * Saved (by means of the "Save" icon) * Exited LibreOffice * Started LibreOffice from the Gnome menu * Opened Test.docx and the text that I had added at the end of the comment was gone.
(In reply to comment #20) > Owen, have you tested with "Save" or with "Save as..."? It seems that only > "Save" triggers the bug. (This may in fact be a strong hint that may help in > finding the bug in the codebase... how does it happen that the textual > content of the file that is generated differs between the results of "Save" > and "Save as..."!?) Aha! This may be the issue. I have been using Save As (to avoid overwriting the original). The testing you have done indicates to me that you are basic using the same platform I did. I will re-test and report back.
If I am understanding this correctly - starting with a fresh profile seems to correct the problem . . . can someone verify this? If this is so, we know at least that it's a corrupt profile issue and there is an easy solution. It's unfortunate that data loss occurred but at least the resetting of the profile fixes it. Please verify the above. Thanks!
(In reply to comment #22) In my tests, starting with a fresh profile avoids the problem in regard to the specific test case that I have identified. Until the bug is better understood, we don't know whether there are situations in which the bug can be triggered with a fresh profile.
Sorry Norbert, I have now thoroughly tested your original file by saving over it again and again under all the versions I have running under Ubuntu 10.04 x86_64 mentioned in comment #8. I have tried adding unquoted text; adding quoted text; editing the German quoted text; moving the German quotation marks to other text. No matter what I do the comment remains as expected (except under v3.3.0.4 as previously mentioned). Because I do a fair amount of testing I tend to have a new profile. This would seem to me to be a profile-related error, which are /very/ common and resolved by a profile reset, as Joel has mentioned. I doubt this is a bug that can be easily duplicated and therefore fixed.
I can confirm with that profile so marking as NEW (but please note that the odds of getting it fixed might be low because it's so specific and can't be reproduced on a fresh profile). As a side note: Whenever saving as something other than our own format, it's best to keep two copies always, one in the open standard, the other in whatever other format you want. Thank you for reporting this issue! I have been able to confirm the issue on: Version 4.1.3.2 Platform: Ubuntu Linux 13.10 x64 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Marking as: New (confirmed) Major -- loss of data High -- default, although a lower importance may be appropriate as it's a broken profile that is causing the issue. Because more than one user faced this same corruption, probably good to leave it as High + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + LibreOffice is powered by a team of volunteers, every bug is confirmed (triaged) by human beings who mostly give their time for free. We invite you to join our triaging by checking out this link: https://wiki.documentfoundation.org/QA/BugTriage There are also other ways to get involved including with marketing, UX, documentation, and of course developing - http://www.libreoffice.org/get-help/mailing-lists/. Lastly, good bug reports help tremendously in making the process go smoother, please always provide reproducible steps (even if it seems easy) and attach any and all relevant material
(In reply to comment #20) > (In reply to comment #18) > Owen, have you tested with "Save" or with "Save as..."? It seems that only > "Save" triggers the bug. (This may in fact be a strong hint that may help in > finding the bug in the codebase... how does it happen that the textual > content of the file that is generated differs between the results of "Save" > and "Save as..."!?) > that's a crucial point. now I'm able to reproduce the bug with 4.1.4 and 3.4.6 releases under Win7 64bit by hitting the "save" toolbar button (p.s. I have maintain current extension at save). interestingly if you "save as" you have no data loss. no data loss even if you edit without saving than hit the "X" to close the document and then select "save" in the pop-up menu that comes out alerting you have modified the document. basically only "toolbar save" triggers the bug, which doesn't happen with "save as" or with "pop-up save when closing after edit"
still reproducible with 4.2.5.2 and 4.4.0.0.alpha0+ Build ID: b9dca968c6fd0ab5ca140c65b0e54d153cd34986 TinderBox: Win-x86@42, Branch:master, Time: 2014-07-18_22:51:20 I edited summary notes to highlight that only toolbar or menu "save" trigger the bug, which instead does not happen with "save as" or "exit, save before closing"
*** Bug 82469 has been marked as a duplicate of this bug. ***
still reproducible with LibO 4.3.1.2 and 4.4.0.0.alpha0+ Build ID: faf99f6f405e076d5c9ab95c876ae1ffb896f8d1 TinderBox: Win-x86@39, Branch:master, Time: 2014-09-26_09:41:28
Created attachment 107153 [details] another test file (In reply to comment #0) > Created attachment 84702 [details] > test document for reproducing the bug > > When comments contain German quote characters "„", "“", upon saving the > document in OOXML format, part of the comment text may be lost. > ... issue is reproducible even if no German quote character is present in the comment. see my attached test .docx file.
(In reply to Norbert Bollow from comment #20) > (In reply to comment #18) > Owen, have you tested with "Save" or with "Save as..."? It seems that only > "Save" triggers the bug. (This may in fact be a strong hint that may help in > finding the bug in the codebase... how does it happen that the textual > content of the file that is generated differs between the results of "Save" > and "Save as..."!?) Yes. But, if "Warn when not saving in ODT or default format" is on, still there's no bug, even with "Save".
still reproducible with 4.4.0.0.alpha2+ Build ID: b021b5983c62e266b82d9f0c5c6d8d8900553827 TinderBox: Win-x86@42, Branch:master, Time: 2014-11-12_00:19:18 LibO 4.2.x reached EOL. moving this to mab4.3 list.
This bug started in the first LO release that supported saving as DOCX. Tested with 3.3.0.4. Since OO didn't support DOCX, not inherited.
Let's set this to inherited from OOo then. Thanks for the update.
still reproducible under Win8.1 x64 using LibO 4.4.3.2 and 5.1.0.0.alpha1+ Build ID: bb9dad2ef23829b2500c9f99154bca6a8ba7d49a TinderBox: Win-x86@39, Branch:master, Time: 2015-06-11_23:59:18 Locale: en-US (it_IT)
Is this really not "inherited from OOo" (this is a regression from the fork)? I've never seen a bug that is a regression from fork at the point of 3.3. @Tommy - can you explain the change? If it's a regression we should tag it in the keywords
(In reply to Timur from comment #33) > This bug started in the first LO release that supported saving as DOCX. > Tested with 3.3.0.4. Since OO didn't support DOCX, not inherited. @Joel I changed the version to 3.3.0.4 since Timur said that OOo did not support DOCX so it's not technically an inherited bug. correct me if I'm wrong
(In reply to Joel Madero from comment #36) > Is this really not "inherited from OOo" (this is a regression from the > fork)? I've never seen a bug that is a regression from fork at the point of > 3.3. Well, there are, because saving to XML is not inherited, it didn't exist, and it was introduced only in LO 3.3. Also Bug 89991, Bug 91153. > @Tommy - can you explain the change? If it's a regression we should tag it > in the keywords It's not a regression, it never worked fine from the beginning.
If this is specific to the config can we binary chop that config right down ? I imagine it is specific only to registrymodifications.xcu - can we do the following: a) whack that file into 5.0 and see if the problems recurr ? if they do then: b) binary-chop the file - (it will need to be pretty-printed first or use an XML editor) to remove the top/bottom alternatively to get this down to a few lines / settings which affect this functionality. I suspect when we've isolated the exact setting (which can be done by any user that can reproduce this) - the fix will become 'obvious' =) Thanks !
Migrating Whiteboard tags to Keywords: (implementationError)
Problem still in 5.2+ (In reply to Michael Meeks from comment #39) I don't understand how is DOCX save filter related to this configuration file. Nor what will change if we delete part of that file that has default settings anyway in new installation. Actually, it's not just that "part of the comment text is lost" but also and "last comment change not saved". This can be tested with multiple comments. The last one is not correctly saved, it's saved with the previous content. To reproduce: - create a document with few comments and save as DOCX - add some text to the comments and then change that text - save using "save" toolbar button or "save" menu item - on reopen, notice that firstly added text is there in the last comment
*** Bug 97410 has been marked as a duplicate of this bug. ***
Dear Bug Submitter, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping-20161207
retested under Win7 x64 using LibO 5.2.3.3 the bug is not reproducible anymore using the "save as" menu item the bug is still reproducible using the "save toolbar button" if you click the button without moving the cursor from the comment box to the page. if instead you edit the comment box, click outside of it placing the cursor inside the document page, the bug does not appear. so partially RESOLVED but still NEW edited summary notes.
*** Bug 73221 has been marked as a duplicate of this bug. ***
still present in LibO 5.4.0.0.alpha0+ Build ID: 5bb5a9dacb84ec14f7148a5a5d9ba38b7e9f1039 CPU Threads: 4; OS Version: Windows 6.29; UI Render: default; TinderBox: Win-x86@42, Branch:master, Time: 2017-02-17_23:30:45 Locale: it-IT (it_IT); Calc: group
Jan Holesovsky committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=4354f0e9ef4a5538729a2a6f2d1745e247f6c5cd tdf#68604: Commit the data from the postit to the model before docx save. It will be available in 5.4.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Should be fixed now :-)
Jan Holesovsky committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=24fee4879c0df4fb88fad8de4f7d62598888aafe related tdf#68604: Write the plaintext version of the annotation... It will be available in 5.4.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Jan Holesovsky committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=26930dfffe791de7d0c88d1a6dcb15498d6f6883 related tdf#68604: Unit test for writing the plaintext annotations in DOCX. It will be available in 5.4.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Looks like fixed. Please backport to 5.3.
*** Bug 105458 has been marked as a duplicate of this bug. ***