Bug Hunting Session
Bug 85523 - Extra blank lines added to comments after each save as .DOCX
Summary: Extra blank lines added to comments after each save as .DOCX
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.1.5.3 release
Hardware: Other All
: medium minor
Assignee: Miklos Vajna
URL:
Whiteboard: target:5.2.0 target:5.1.2 target:5.0.6
Keywords: bibisected, bisected, filter:docx, regression
: 92312 (view as bug list)
Depends on:
Blocks:
 
Reported: 2014-10-27 16:56 UTC by braingamer47
Modified: 2018-02-11 22:08 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments
"X" letters at the end of comments are appearing themselves (13.20 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2015-06-28 17:53 UTC, Maris Nartiss
Details

Note You need to log in before you can comment on or make changes to this bug.
Description braingamer47 2014-10-27 16:56:15 UTC
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
Comment 1 tommy27 2014-10-28 04:19:36 UTC
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.
Comment 2 Yousuf Philips (jay) (retired) 2014-12-03 15:30:21 UTC
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
Comment 3 Matthew Francis 2014-12-03 15:33:34 UTC
This is not reproducible under Linux, so unfortunately not a candidate for bibisect
Comment 4 Maris Nartiss 2015-06-28 13:26:35 UTC
(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
Comment 5 Yousuf Philips (jay) (retired) 2015-06-28 14:35:49 UTC
(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.
Comment 6 Maris Nartiss 2015-06-28 17:53:37 UTC
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.
Comment 7 Yousuf Philips (jay) (retired) 2015-08-03 17:08:30 UTC
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.
Comment 8 Michael Weghorn 2015-08-03 21:04:37 UTC
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?
Comment 9 Robinson Tryon (qubit) 2015-12-13 12:15:49 UTC Comment hidden (obsolete)
Comment 10 Miklos Vajna 2016-01-15 22:08:47 UTC
(In reply to Michael Weghorn from comment #8)
> @Miklos: Could you possibly have a look at this?

I'll take care of this.
Comment 11 Commit Notification 2016-01-19 08:29:16 UTC
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.
Comment 12 Yousuf Philips (jay) (retired) 2016-01-19 08:57:23 UTC
Thanks Miklos for the fix. It would be good to backport this into 5.0 and 5.1.
Comment 13 Miklos Vajna 2016-01-19 16:36:54 UTC
Yes, it's in my backport queue. :-)
Comment 14 Commit Notification 2016-02-11 15:56:10 UTC
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.
Comment 15 Commit Notification 2016-02-12 20:39:53 UTC
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.
Comment 16 Gabor Kelemen 2018-02-11 22:08:29 UTC
*** Bug 92312 has been marked as a duplicate of this bug. ***