Using 4.3.2.2 and saving as a .docx file, whenever you save the document, and have comments, and extra return is added to the comment. First save it has one line. Second save, 1 extra blank line. 3rd save, 2 extra blank lines. It gets very annoying. You can delete them, but the next time you open it up, all comments have an extra line in them again. Save, open again (if you don't manually delete them) and they all have two extra lines etc. I have windows 7 ultimate if that helps. Haven't tried it in ubuntu 14.04 yet. Brian Truskey
I confirm bug under Win7x64 using recent LibO 4.4.0.0+ master, 4.3.2.2, 4.2.0.4, and 4.1.5.3 works fine with 4.1.3.2 hence it's a regression that needs bibisecting. saving as .odt or .doc has no issue.
Seems like a windows only bug. Version: 4.5.0.0.alpha0+ Build ID: 5f7261651647e0d3de70c8cab99ef9b5a26de557 TinderBox: Linux-rpm_deb-x86@45-TDF, Branch:master, Time: 2014-12-02_09:43:47
This is not reproducible under Linux, so unfortunately not a candidate for bibisect
(In reply to Matthew Francis from comment #3) > This is not reproducible under Linux, so unfortunately not a candidate for > bibisect I have a docx document that exhibits similar issue on Linux. The difference from original report - it adds "X" letter at the end of comments; not all comments are affected, still I fail to observe any logic behind affected comments (creation time, part of document etc.); document has "track changes"; it has been created with MS-Word. I can e-mail the document on request for testing. Version: 4.4.3.2 Build ID: 88805f81e9fe61362df02b9941de8e38a9b5fd16 Locale: lv_LV
(In reply to Maris Nartiss from comment #4) > I can e-mail the document on request for testing. Hi Maris, Is it possible to attach the document to this bug report by clicking the 'Add an attachment' link on this page.
Created attachment 116899 [details] "X" letters at the end of comments are appearing themselves Lucky the issue is still present also after removing most of the document content. Still, now "X"es are growing only for a single comment ("quartzite"), the rest of comments seem to be "cured". Steps to reproduce issue - just edit the document; save; close document; open it again.
Thanks Maris for the test document. The docx was created in 4.3.7 and when you open it with 4.4 and above, the "quartzite" comment has 7 X's rather than 6. So this seems to be a FILEOPEN issue that only occurs with docx. Build ID: 902255645328efde34ddf62227c8278e8dd61ff0 TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2015-07-30_05:23:12 Locale: en-US (en_US.UTF-8) This seems somewhat different to the bug description and tommy's confirmation, but without a document from the bug reporter, it would be hard to track that issue down.
bibisect result for the bug described in comment 7 ("7 X's rather than 6"; using the bibisect-44max repository): 4b617ae69933611ff6d2f0c4509b823aba4eb61b is the first bad commit commit 4b617ae69933611ff6d2f0c4509b823aba4eb61b Author: Matthew Francis <mjay.francis@gmail.com> Date: Sat Mar 14 23:22:10 2015 +0800 source-hash-fc3eb493ac9e8dec35060524db4dc8ca3210631a commit fc3eb493ac9e8dec35060524db4dc8ca3210631a Author: Miklos Vajna <vmiklos@collabora.co.uk> AuthorDate: Tue Jul 15 18:18:19 2014 +0200 Commit: Miklos Vajna <vmiklos@collabora.co.uk> CommitDate: Tue Jul 15 19:05:06 2014 +0200 Related: bnc#875718 DOCX import: fix missing character grab-bag on fields The problem was that in case: 1) The paragraph only had a single text portion, which was a field and char grab-bag was set on it and 2) The paragraph had a style which also set the character grab-bag then during import the field's gra-bag was set on the paragraph (as it's the only portion) and later the paragraph style overwrote this, in case that had a grab-bag, too. Work this around by ensuring that in case of portion fields (i.e. not ToC, which has its own paragraphs), there are always at least two portions in a paragraph (the second is removed later). This also fixes the fake paragraph problem at the end of the bnc#875718 testcase. (There was an empty paragraph at the end of the document, but not in the file itself.) Change-Id: Ie404bc043d46157ea6157b18c4a46395cf496118 :040000 040000 d6c048cfdb5da8bce4463a1eb0f345e6a9d2de46 37149caae29d7afcee26d0cee6be4c772520b68c M opt --- $ git bisect log # bad: [cf6ea17155fabb2a120ba07c150735591ac861d7] source-hash-3f94c9e9ddfd807b449f3bb9b232cf2041fa12d2 # good: [fc71ac001f16209654d15ef8c1c4018aa55769f5] source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e git bisect start 'latest' 'oldest' # bad: [8cf60cc706948588e2f33a6d98b7c55d454e362a] source-hash-f340f0454627939f1830826fb5cc53a90e6c62a4 git bisect bad 8cf60cc706948588e2f33a6d98b7c55d454e362a # good: [d9885f526fc7a09cc8f9f8ee643af1b966be24bb] source-hash-d1465c64c6f64ad8dd25e40cdc69649b24b305ea git bisect good d9885f526fc7a09cc8f9f8ee643af1b966be24bb # bad: [c779cf7967f4d14c5e649a5c696b07279d550efd] source-hash-e9c5022580f14c0ca97503f8b3cc56b530fff174 git bisect bad c779cf7967f4d14c5e649a5c696b07279d550efd # good: [030e0477638f9d9110ad62f88fd4b881521e0541] source-hash-1a6e47e3fda10e6d220b67d766ec6fbdfd852b80 git bisect good 030e0477638f9d9110ad62f88fd4b881521e0541 # bad: [c9e7f255b30a0410226b2074702aeba9b49dce13] source-hash-2d5a7c36ee9ae7ff39d8415f81fb911ff822548e git bisect bad c9e7f255b30a0410226b2074702aeba9b49dce13 # bad: [d0dbfc8071785ec97868d0a98dec934d9eb81e5c] source-hash-24b6add3774f5f0807c907d5a233ba8ac11116f4 git bisect bad d0dbfc8071785ec97868d0a98dec934d9eb81e5c # bad: [42270516a592a0472a672fc7058499203b949f21] source-hash-a3b6e0da35987af441042bd444c331d78a7c69b5 git bisect bad 42270516a592a0472a672fc7058499203b949f21 # bad: [03559c28ca7da90f6ef795f10d1bcdb0cbd332f2] source-hash-6e6cbf44d80ffff6457512c142c64cf857eacfaa git bisect bad 03559c28ca7da90f6ef795f10d1bcdb0cbd332f2 # good: [6ab006a48b5360de35387b6f7a566ba8d4dcec3c] source-hash-a5d4e237049abec3b6c7d13f25d8bb0773d1df5a git bisect good 6ab006a48b5360de35387b6f7a566ba8d4dcec3c # good: [20ae1c2fbd48552dede24202ed60ee795e7827ed] source-hash-ffe7faf8950eba541606d22ce7a50483fd4c84f4 git bisect good 20ae1c2fbd48552dede24202ed60ee795e7827ed # good: [5f3dddf8b3f9855f5ee04f069acc5471b9b9af13] source-hash-94b3b4fdf1023396287894c0d985683b48f55099 git bisect good 5f3dddf8b3f9855f5ee04f069acc5471b9b9af13 # good: [402ce18f4987cdb94b17d3786c33bbb96c170de0] source-hash-b409aaa7d65151106236058d3c478bd7f87dd296 git bisect good 402ce18f4987cdb94b17d3786c33bbb96c170de0 # bad: [4b617ae69933611ff6d2f0c4509b823aba4eb61b] source-hash-fc3eb493ac9e8dec35060524db4dc8ca3210631a git bisect bad 4b617ae69933611ff6d2f0c4509b823aba4eb61b # good: [5bfdb722a363a19eb24a17b6a049b1321f8a702c] source-hash-6d3269ad94bbad8abae5703edc86d8888356bf14 git bisect good 5bfdb722a363a19eb24a17b6a049b1321f8a702c # first bad commit: [4b617ae69933611ff6d2f0c4509b823aba4eb61b] source-hash-fc3eb493ac9e8dec35060524db4dc8ca3210631a @Miklos: Could you possibly have a look at this?
Migrating Whiteboard tags to Keywords: (bibisected, filter:docx) [NinjaEdit]
(In reply to Michael Weghorn from comment #8) > @Miklos: Could you possibly have a look at this? I'll take care of this.
Miklos Vajna committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=39969defa29948d77565a7cd8a3471baaec8f35d tdf#85523 DOCX import: fix unexpected extra char at comment end It will be available in 5.2.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.
Thanks Miklos for the fix. It would be good to backport this into 5.0 and 5.1.
Yes, it's in my backport queue. :-)
Miklos Vajna committed a patch related to this issue. It has been pushed to "libreoffice-5-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=2f57811486e9e57a1634fbdeca0349b896fabab0&h=libreoffice-5-1 tdf#85523 DOCX import: fix unexpected extra char at comment end It will be available in 5.1.2. 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.
Miklos Vajna committed a patch related to this issue. It has been pushed to "libreoffice-5-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=10a142356a4cdb487da10d83857e4b50a0452a5b&h=libreoffice-5-0 tdf#85523 DOCX import: fix unexpected extra char at comment end It will be available in 5.0.6. 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.
*** Bug 92312 has been marked as a duplicate of this bug. ***