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.
Created attachment 116595 [details] good.docx - identical-looking doc which does NOT have the bug
REGRESSION since 4.4.2.2
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)
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
Adding Cc: to vmiklos (myself) since this is in fact bisected.
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.
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.
I see the fix in daily dbgutil bibisect version 2015-09-24.
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.
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]