Bug Hunting Session
Bug 92124 - Internal corruption prevents BS or DEL deleting final paragraph (after copy/paste or import?)
Summary: Internal corruption prevents BS or DEL deleting final paragraph (after copy/p...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.0.0.0.beta1
Hardware: Other All
: medium normal
Assignee: Miklos Vajna
URL:
Whiteboard: target:5.1.0 target:5.0.3
Keywords: bibisected, bisected, regression
Depends on:
Blocks:
 
Reported: 2015-06-16 21:37 UTC by Jim Avera
Modified: 2016-10-25 19:20 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
bad.docx - document which exhibits the bug (7.25 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2015-06-16 21:37 UTC, Jim Avera
Details
good.docx - identical-looking doc which does NOT have the bug (4.47 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2015-06-16 21:38 UTC, Jim Avera
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jim Avera 2015-06-16 21:37:53 UTC
Created attachment 116594 [details]
bad.docx - document which exhibits the bug

In certain documents, the last paragraph can not be deleted by normal keystrokes, such as the Backspace or DEL keys.  Some (unknown) sequence of copy and paste, or possibly conversion from .odt to .docx format breaks something which renders Backspace and DEL impotent when the cursor is in the last paragraph of the document and the paragraph has no text.

Attached please find two seemingly-identical documents.  The one named "good.docx" has no problem -- you can delete the final paragraph at will.  The other one, named "bad.docx" does not let you delete the final paragraph.

Hopefully a dev can figure out what is different about "bad.docx" and how to prevent it from happening.

STEPS TO REPRODUCE:

1.  Open the attached "bad.docx"
2.  Place cursor at the very end of the last paragrah
3.  Press Backspace repeatedly

Actual results: You can not Backspace past the start of the paragraph, i.e., you can not remove the paragraph and back up to the previous one.  DEL doesn't work either

Expected Results: Backspace should keep deleting into the preceding paragraph, which is the behavior if you open the attached "good.docx" instead.
Comment 1 Jim Avera 2015-06-16 21:38:34 UTC
Created attachment 116595 [details]
good.docx - identical-looking doc which does NOT have the bug
Comment 2 Jim Avera 2015-06-16 21:42:53 UTC
REGRESSION since 4.4.2.2
Comment 3 Buovjaga 2015-06-17 09:09:22 UTC
In the bad.docx, I confirm I can't delete the line break with backspace. If I go to the previous line, I can delete the offending break with Delete key.

In 4.4 backspace works.

Win 7 Pro 64-bit, Version: 4.4.3.2
Build ID: 88805f81e9fe61362df02b9941de8e38a9b5fd16
Locale: fi_FI

Version: 5.1.0.0.alpha1+
Build ID: 80ec99db4325a439a8a3f1d420d0a80f8bf9c439
TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2015-06-16_00:00:20
Locale: fi-FI (fi_FI)

Ubuntu 15.04 64-bit 
Version: 5.1.0.0.alpha1+
Build ID: 9ef671364ff9fbb552a5433053af9283d12d90c7
TinderBox: Linux-rpm_deb-x86_64@46-TDF-dbg, Branch:master, Time: 2015-06-16_08:38:45
Locale: en-US (en_US.UTF-8)
Comment 4 Terrence Enger 2015-06-17 17:00:53 UTC
Working in the 50max bibisect repository, I see from `git bisect bad` ...

    88385ccedaa5a41cf5c76b6c815fdc93c7cc9bb8 is the first bad commit
    commit 88385ccedaa5a41cf5c76b6c815fdc93c7cc9bb8
    Author: Matthew Francis <mjay.francis@gmail.com>
    Date:   Wed May 27 17:27:54 2015 +0800

        source-hash-e155e05ab70f1744d296dbee8c61564a5b7d346c
    
        commit e155e05ab70f1744d296dbee8c61564a5b7d346c
        Author:     Miklos Vajna <vmiklos@collabora.co.uk>
        AuthorDate: Fri Dec 19 16:26:59 2014 +0100
        Commit:     Miklos Vajna <vmiklos@collabora.co.uk>
        CommitDate: Fri Dec 19 17:32:06 2014 +0100
    
            DOCX filter: handle decimal number format with no level text correctly
    
            The first problem was that no level text means no list text in Word, but
            Writer only does that for the "none" numbering format.
    
            Also, when the numbering format is "none", then Writer doesn't show the
            follow character (typically a tab), either, but Word does: add a zero
            width space as a suffix to mimic the Word behavior on DOCX import.
    
            Adapt CppunitTest_sw_rtfimport accordingly, that effectively tested that
            LabelFollowedBy is lost on import.
    
            Change-Id: I7d5c7e62ba3d02da4a750ba5afad07e68b0b8c38

    :040000 040000 30d8141e22b7f00c335d9b22b3b3502d18b49450 04e2fd45eb909238f0fbe4c52e1c2a6eec512a30 M	opt

and from `git bisect log` ...

    # bad: [dda106fd616b7c0b8dc2370f6f1184501b01a49e] source-hash-0db96caf0fcce09b87621c11b584a6d81cc7df86
    # good: [5b9dd620df316345477f0b6e6c9ed8ada7b6c091] source-hash-2851ce5afd0f37764cbbc2c2a9a63c7adc844311
    git bisect start 'latest' 'oldest'
    # bad: [0c30a2c797b249d0cd804cb71554946e2276b557] source-hash-45aaec8206182c16025cbcb20651ddbdf558b95d
    git bisect bad 0c30a2c797b249d0cd804cb71554946e2276b557
    # bad: [770ff0d1a74d2450c2decb349b62c5087e12c46b] source-hash-549b7fad48bb9ddcba7dfa92daea6ce917853a03
    git bisect bad 770ff0d1a74d2450c2decb349b62c5087e12c46b
    # good: [227af65db5e34efcf8dcb0b53333efecd30f37f8] source-hash-193c7ba9be48f00b46f9e789f233db577e7b3303
    git bisect good 227af65db5e34efcf8dcb0b53333efecd30f37f8
    # good: [78b395d05689a5207f2ec4cc29ec296d64076a96] source-hash-a2e4be6ded508030a6c2a33919cbe8cb504382e0
    git bisect good 78b395d05689a5207f2ec4cc29ec296d64076a96
    # bad: [8dd6442885c969ae43ae5ff9ddfc53c9f04a9c27] source-hash-d07f0997c54e9cef31d996ebeb2aabfb4b4e0265
    git bisect bad 8dd6442885c969ae43ae5ff9ddfc53c9f04a9c27
    # bad: [0c544096152075c642ed598111cb02e8b74161ee] source-hash-1ac3ad7743c7c98b83f7a8a4c3e03a83721b46b9
    git bisect bad 0c544096152075c642ed598111cb02e8b74161ee
    # good: [80f9488222ce032799b51c38d9efb7d6e9d98fc4] source-hash-68d87e98951ae3ed5f7b863954667bfdd9805985
    git bisect good 80f9488222ce032799b51c38d9efb7d6e9d98fc4
    # bad: [06973d6ff6586778cb931191d01d6cd192332e6f] source-hash-9adb00cf4df13e6f251c0ff5f71bce5ca2c7525d
    git bisect bad 06973d6ff6586778cb931191d01d6cd192332e6f
    # good: [cb72224396480e9172e6e801d0db5ccfa8e82b37] source-hash-170c7ee2f6f902d9de139b914b74e807b28da0a9
    git bisect good cb72224396480e9172e6e801d0db5ccfa8e82b37
    # good: [3240f6ac5bd6aa822a9d1fb9421b929aee170e97] source-hash-5712983f18e7cdec16ea20a9b3d94a1586de543e
    git bisect good 3240f6ac5bd6aa822a9d1fb9421b929aee170e97
    # good: [fb86caa4ad382e9611eef954ac4cc351933c408b] source-hash-2171c3dd49694b4928b0a04b76d3c42a2b18f6cc
    git bisect good fb86caa4ad382e9611eef954ac4cc351933c408b
    # good: [b4a45028c047832c96de55ef47f3e49e790df083] source-hash-f3d54642672b4a4fb6cca0c2439744189de5f0bc
    git bisect good b4a45028c047832c96de55ef47f3e49e790df083
    # bad: [88385ccedaa5a41cf5c76b6c815fdc93c7cc9bb8] source-hash-e155e05ab70f1744d296dbee8c61564a5b7d346c
    git bisect bad 88385ccedaa5a41cf5c76b6c815fdc93c7cc9bb8
    # first bad commit: [88385ccedaa5a41cf5c76b6c815fdc93c7cc9bb8] source-hash-e155e05ab70f1744d296dbee8c61564a5b7d346c
Comment 5 Miklos Vajna 2015-08-31 13:02:35 UTC
Adding Cc: to vmiklos (myself) since this is in fact bisected.
Comment 6 Miklos Vajna 2015-09-22 16:03:54 UTC
This can be fixed at two levels -- one would be to deal with the 0x200B numbering Suffix in sw core when turning a paragraph-in-a-list into a paragraph (this is not implemented, and never worked), the other one is to let the DOCX import not produce such a Suffix when it's not needed, like for the above document.

Since this is a regression, I'm going with the second approach for this bug.
Comment 7 Commit Notification 2015-09-23 05:51:22 UTC
Miklos Vajna committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=3e27df1035677c7cca5200858d5d8e8283bf7aa9

tdf#92124 DOCX import: don't add a dummy Suffix for an empty LabelFollowedBy

It will be available in 5.1.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 8 Terrence Enger 2015-09-24 23:31:24 UTC
I see the fix in daily dbgutil bibisect version 2015-09-24.
Comment 9 Commit Notification 2015-10-01 09:25:14 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=c33af041298fc4897ee1215efda488654955ebf7&h=libreoffice-5-0

tdf#92124 DOCX import: don't add a dummy Suffix for an empty LabelFollowedBy

It will be available in 5.0.3.

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 10 Robinson Tryon (qubit) 2015-12-17 09:13:52 UTC Comment hidden (obsolete)