Bug 68604 - FILESAVE: last comment change with cursor within box not saved in .docx using "save" toolbar button (see Comment 41 and Comment 44)
Summary: FILESAVE: last comment change with cursor within box not saved in .docx using...
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: filters and storage (show other bugs)
Version:
(earliest affected)
3.3.0 release
Hardware: All All
: highest major
Assignee: Not Assigned
URL:
Whiteboard: interoperability target:5.4.0
Keywords: filter:docx, implementationError
: 73221 82469 97410 105458 (view as bug list)
Depends on:
Blocks:
 
Reported: 2013-08-27 11:38 UTC by Norbert Bollow
Modified: 2017-06-09 15:20 UTC (History)
10 users (show)

See Also:
Crash report or crash signature:


Attachments
test document for reproducing the bug (4.58 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2013-08-27 11:38 UTC, Norbert Bollow
Details
test file saved under Windows (4.65 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2013-08-30 09:38 UTC, tommy27
Details
DOCX test file saved under various OS/LO versions. (65.65 KB, application/zip)
2013-12-09 00:44 UTC, Owen Genat (retired)
Details
contents of ~/.config/libreoffice to reproduce the bug (212.19 KB, application/x-gzip)
2013-12-17 10:50 UTC, Norbert Bollow
Details
another test file (4.94 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2014-09-30 20:30 UTC, tommy27
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Norbert Bollow 2013-08-27 11:38:29 UTC
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)
Comment 1 tommy27 2013-08-29 12:56:40 UTC
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?
Comment 2 Norbert Bollow 2013-08-29 22:10:59 UTC
I've just tried Version: 4.1.1.2 (Build ID: 7e4286b58adc75a14f6d83f53a03b6c11fa2903)... it is still affected.
Comment 3 tommy27 2013-08-30 09:38:39 UTC
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?
Comment 4 Norbert Bollow 2013-09-10 19:48:07 UTC
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.
Comment 5 Norbert Bollow 2013-09-10 19:59:50 UTC
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).
Comment 6 Norbert Bollow 2013-09-11 11:07:44 UTC
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.
Comment 7 Matt Price 2013-12-03 17:21:51 UTC
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!
Comment 8 Owen Genat (retired) 2013-12-09 00:44:45 UTC
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).
Comment 9 Owen Genat (retired) 2013-12-09 00:50:09 UTC
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.
Comment 10 Norbert Bollow 2013-12-09 10:29:41 UTC
All of my tests have been with IA32 and with LANG=de_CH.UTF-8
Comment 11 Owen Genat (retired) 2013-12-09 11:56:41 UTC
(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. :-(
Comment 12 Norbert Bollow 2013-12-09 13:23:43 UTC
(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?
Comment 13 Owen Genat (retired) 2013-12-09 21:49:43 UTC
(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.
Comment 14 Owen Genat (retired) 2013-12-15 03:55:48 UTC
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.
Comment 15 Norbert Bollow 2013-12-16 15:12:01 UTC
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.
Comment 16 Norbert Bollow 2013-12-17 10:50:00 UTC
Created attachment 90872 [details]
contents of ~/.config/libreoffice to reproduce the bug
Comment 17 Norbert Bollow 2013-12-17 10:55:36 UTC
(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)).
Comment 18 Owen Genat (retired) 2013-12-19 06:33:15 UTC
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.
Comment 19 Norbert Bollow 2013-12-19 14:54:09 UTC
(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.
Comment 20 Norbert Bollow 2013-12-20 12:18:42 UTC
(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.
Comment 21 Owen Genat (retired) 2013-12-21 13:23:46 UTC
(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.
Comment 22 Joel Madero 2013-12-21 18:58:17 UTC
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!
Comment 23 Norbert Bollow 2013-12-21 19:17:36 UTC
(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.
Comment 24 Owen Genat (retired) 2013-12-22 09:59:23 UTC
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.
Comment 25 Joel Madero 2013-12-22 15:42:44 UTC
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
Comment 26 tommy27 2014-01-02 14:00:19 UTC
(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"
Comment 27 tommy27 2014-07-20 08:50:53 UTC
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"
Comment 28 tommy27 2014-09-30 19:19:57 UTC
*** Bug 82469 has been marked as a duplicate of this bug. ***
Comment 29 tommy27 2014-09-30 19:33:30 UTC
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
Comment 30 tommy27 2014-09-30 20:30:43 UTC
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.
Comment 31 Timur 2014-10-20 12:03:18 UTC
(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".
Comment 32 tommy27 2014-11-20 03:05:27 UTC
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.
Comment 33 Timur 2015-02-09 19:07:31 UTC
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.
Comment 34 Joel Madero 2015-02-09 20:46:37 UTC
Let's set this to inherited from OOo then. Thanks for the update.
Comment 35 tommy27 2015-06-15 20:53:49 UTC
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)
Comment 36 Joel Madero 2015-06-16 14:14:20 UTC
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
Comment 37 tommy27 2015-06-16 14:45:15 UTC
(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
Comment 38 Timur 2015-06-16 15:36:04 UTC
(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.
Comment 39 Michael Meeks 2015-10-16 08:44:25 UTC
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 !
Comment 40 Robinson Tryon (qubit) 2015-12-10 10:05:06 UTC Comment hidden (obsolete)
Comment 41 Timur 2016-02-03 16:47:44 UTC
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
Comment 42 Timur 2016-02-04 08:55:15 UTC
*** Bug 97410 has been marked as a duplicate of this bug. ***
Comment 43 QA Administrators 2016-12-07 12:42:21 UTC Comment hidden (obsolete)
Comment 44 tommy27 2016-12-07 17:01:29 UTC
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.
Comment 45 Timur 2016-12-09 19:00:49 UTC
*** Bug 73221 has been marked as a duplicate of this bug. ***
Comment 46 tommy27 2017-02-18 20:18:43 UTC
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
Comment 47 Commit Notification 2017-04-21 06:08:35 UTC
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.
Comment 48 Jan Holesovsky 2017-04-21 06:29:03 UTC
Should be fixed now :-)
Comment 49 Commit Notification 2017-04-21 10:40:56 UTC
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.
Comment 50 Commit Notification 2017-04-21 10:41:33 UTC
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.
Comment 51 Timur 2017-04-28 17:59:21 UTC
Looks like fixed. Please backport to 5.3.
Comment 52 Timur 2017-06-09 15:20:03 UTC
*** Bug 105458 has been marked as a duplicate of this bug. ***