Bug 104315 - Creating a table of contents with a whitespace between Entry and Tab stop causes the last character of the entry to be removed
Summary: Creating a table of contents with a whitespace between Entry and Tab stop cau...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.3.0.0.beta1
Hardware: All All
: high major
Assignee: Not Assigned
QA Contact:
URL:
Whiteboard: target:5.4.0 target:5.3.1
Keywords: bibisected, bisected, regression
: 105698 105758 105763 105859 105916 106003 106005 106017 106036 106092 106258 (view as bug list)
Depends on:
Blocks:
 
Reported: 2016-12-01 07:23 UTC by wolff-ohlenberg
Modified: 2017-03-02 11:51 UTC (History)
19 users (show)

See Also:
Crash report or crash signature:


Attachments
Please open it with LO-Version 5.2.4.1 and 5.3.0.0.b1 and above. Then the diffrence is shown. The same is happened by the index. (11.28 KB, application/vnd.oasis.opendocument.text)
2016-12-03 07:19 UTC, wolff-ohlenberg
Details
Screenshot with 5.2.3 and 5.4 (257.42 KB, image/jpeg)
2016-12-03 19:07 UTC, Buovjaga
Details
The expected result in 5.2 (110.63 KB, image/jpeg)
2016-12-03 20:57 UTC, wolff-ohlenberg
Details
The case happened, when I set a blank before T and set a blank behind T (110.63 KB, image/jpeg)
2016-12-05 13:27 UTC, wolff-ohlenberg
Details
Example file showing and describing the problem with another character than space (52.65 KB, application/vnd.oasis.opendocument.text)
2017-02-13 08:26 UTC, Lars Jødal
Details

Note You need to log in before you can comment on or make changes to this bug.
Description wolff-ohlenberg 2016-12-01 07:23:39 UTC
Hello to all,

in 5.3.0.0.beta1 and above in the configuration for the directories I've set a blank before and bihind the tab. When I create the directories, there are backspaces set for the blanks.

Best regards, Helmut!
Comment 1 tommy27 2016-12-02 04:14:34 UTC
sorry I don't understand... would you please try to rephrase or post a screenshot?
Comment 2 Buovjaga 2016-12-02 19:57:44 UTC
Yes, a pic would be awesome.

Set to NEEDINFO.
Change back to UNCONFIRMED after you have provided the screenshot.
Comment 3 wolff-ohlenberg 2016-12-03 07:19:39 UTC
Created attachment 129273 [details]
Please open it with LO-Version 5.2.4.1 and 5.3.0.0.b1 and above. Then the diffrence is shown. The same is happened by the index.
Comment 4 Buovjaga 2016-12-03 19:07:23 UTC Comment hidden (obsolete)
Comment 5 wolff-ohlenberg 2016-12-03 20:57:36 UTC
Created attachment 129290 [details]
The expected result in 5.2
Comment 6 Buovjaga 2016-12-04 13:46:07 UTC
Ok thanks to Dennis on IRC, I finally got what is the problem.

Repro steps for a completely new document:

1. Type Title1 and set its style to Heading 1
2. Insert - Table of contents.. - Table of contents..
3. Entries tab: click to the white field between E and T and type a space
4. Click OK and observe the result

In 5.3, the 1 from Title1 is chomped away.
Comment 7 Aron Budea 2016-12-05 09:21:10 UTC
Adding Cc: to Abhilash (abhilash300singh@gmail.com).
Also adding Cc: to jan iversen (committer).
Please take a look.

https://cgit.freedesktop.org/libreoffice/core/commit/?id=250252d02bac88877845a4bc27e3f1837f1312ba
tdf#44282 fix missing space for numbered lists in TOC


Bibisect details:

c3007fb15c1ced9b37e5460f585e72a497efdeec is the first bad commit
commit c3007fb15c1ced9b37e5460f585e72a497efdeec
Author: Jenkins Build User <tdf@pollux.tdf>
Date:   Tue Oct 25 11:18:56 2016 +0200

    source sha:250252d02bac88877845a4bc27e3f1837f1312ba
    
    source sha:250252d02bac88877845a4bc27e3f1837f1312ba


# bad: [b356e15c1f14e3d0f0bb73662c878d14fc8aa992] source sha:ada8a2123ea655142be74a11c23e042a0109d5f8
# good: [09613c3ea582c72cd064e1627766e3e96c196ebf] source sha:5b168b3fa568e48e795234dc5fa454bf24c9805e
git bisect start 'b356e15c1f14e3d0f0bb73662c878d14fc8aa992' '09613c3ea582c72cd064e1627766e3e96c196ebf'
# good: [78a4f08cf26d3f800710c509a99b1f4ad8a4e783] source sha:db231633af4667e24281e0be69ab63ad3081fdc3
git bisect good 78a4f08cf26d3f800710c509a99b1f4ad8a4e783
# good: [d9f68fca812338acc473efb5053add57fbdf6415] source sha:8fab6ab36589d0dcd75d45feab43a0b06b7f2a3e
git bisect good d9f68fca812338acc473efb5053add57fbdf6415
# bad: [ed68fdb510a1b043a83cd50a28ee77bdd9ea943d] source sha:ae3fb69ebca4e253959cdf9bf620296e7797a501
git bisect bad ed68fdb510a1b043a83cd50a28ee77bdd9ea943d
# skip: [4fa90d2aa58fa9fd7ede2fdc86ee899d8faf8873] source sha:81dde672f15965cf77b041c1991bd260c4774278
git bisect skip 4fa90d2aa58fa9fd7ede2fdc86ee899d8faf8873
# skip: [5252aaac3066a8ee85aa5168ebedb3591b59da8e] source sha:918d85a82d6535932118247a7fb754dde9f49cd1
git bisect skip 5252aaac3066a8ee85aa5168ebedb3591b59da8e
# good: [cff3c3864a46cefde1b6e3145995b28ae6f9f008] source sha:0d93900801224b797741e9a1abf305109fa35665
git bisect good cff3c3864a46cefde1b6e3145995b28ae6f9f008
# good: [35698108d9ad331d50766bc0dc3fd82cd2478d2c] source sha:75ab2019a577813bcca2cdbe6aae38187cb52b50
git bisect good 35698108d9ad331d50766bc0dc3fd82cd2478d2c
# good: [ab310e669ca8d4163d13d21e38b3c1673d571577] source sha:9ab408277b8c68f3d987a36744171fc0ef1de2f6
git bisect good ab310e669ca8d4163d13d21e38b3c1673d571577
# good: [3f21e7237c02bd224ec2f9e7aefa94be6129612d] source sha:27a4fb657fad157d26d07934ecd0cce578a99f38
git bisect good 3f21e7237c02bd224ec2f9e7aefa94be6129612d
# good: [4442ae9f0cf2b930f1b4385c3157bdda6398913a] source sha:d129099624d2b646d975c9567541ed9c18adb7ef
git bisect good 4442ae9f0cf2b930f1b4385c3157bdda6398913a
# good: [a2103183a3d4865b6801657fc88cf913d46b9039] source sha:59ec27f44630fe129a590ba4caf6998bb671ecb5
git bisect good a2103183a3d4865b6801657fc88cf913d46b9039
# good: [05f356b59ce0ea831de9f0d90d1e8f247dbe9df4] source sha:681a1ca27f606282a1fb3a60d67f61c0f3ba9579
git bisect good 05f356b59ce0ea831de9f0d90d1e8f247dbe9df4
# bad: [c4d16dbfec2e2e9c0d78bf4b45050052931011cc] source sha:461e9cc64b5a6e9943db397d27c6415327386494
git bisect bad c4d16dbfec2e2e9c0d78bf4b45050052931011cc
# good: [0831975e520cc606461ad936fbd0e0099292733a] source sha:0560f6cc3cd83923f03ec909a1771c6a984ee25d
git bisect good 0831975e520cc606461ad936fbd0e0099292733a
# good: [22b6b1216810b1b539b1aa484bd4b10808c99819] source sha:8ae33b1652cb1e654c426350169d3bb9fa031a4f
git bisect good 22b6b1216810b1b539b1aa484bd4b10808c99819
# bad: [c3007fb15c1ced9b37e5460f585e72a497efdeec] source sha:250252d02bac88877845a4bc27e3f1837f1312ba
git bisect bad c3007fb15c1ced9b37e5460f585e72a497efdeec
# first bad commit: [c3007fb15c1ced9b37e5460f585e72a497efdeec] source sha:250252d02bac88877845a4bc27e3f1837f1312ba
Comment 8 abhilash300singh 2016-12-05 10:29:17 UTC
I had written that patch thinking( after reading this http://opengrok.libreoffice.org/xref/core/sw/inc/tox.hxx#177 )  that case TOKEN_TEXT is only hit when the user types something between E# and E.  Seems I'm not fully clear on when different cases are hit. Any explanations on when these cases are hit will help. I'll take a look again. 

Thanks.
Comment 9 wolff-ohlenberg 2016-12-05 13:27:18 UTC
Created attachment 129322 [details]
The case happened, when I set a blank before T and set a blank behind T
Comment 10 wolff-ohlenberg 2016-12-20 07:38:56 UTC
Dear all,

there is happened nothing for 2 weeks.
Is the bug working in process?
I'm still interessted in the development of the bug.
I've installed Version 5.3.0.0.b2. There the bug is continued.

For all I wish a merry christmas and a happy new year, Helmut!
Comment 11 tommy27 2016-12-20 07:51:10 UTC
please do not change status field. the bug was already confirmed so correct status is NEW, not UNCONFIRMED
Comment 12 wolff-ohlenberg 2016-12-27 06:09:08 UTC
Dear all,

I've installed Version 5.3.0.1.
The bug isn't fixed. What can I do for the answer to the problem?

Best regards, Helmut!
Comment 13 tommy27 2016-12-27 08:17:37 UTC
consider that is Xmas time and development is slow in this period.
Comment 14 wolff-ohlenberg 2017-01-29 07:05:20 UTC
Hello,

what's the matter with my bug? - Version 5.3.0.3 may be downloaded. The bug is still find.

My regards, Helmut Wolff!
Comment 15 Aron Budea 2017-02-03 03:28:31 UTC
*** Bug 105698 has been marked as a duplicate of this bug. ***
Comment 16 Aron Budea 2017-02-03 03:31:32 UTC
Would it be possible to revert the offending commit until a better fix is found? Thanks!
Comment 17 Aron Budea 2017-02-04 23:37:42 UTC
*** Bug 105758 has been marked as a duplicate of this bug. ***
Comment 18 JoNi 2017-02-05 13:29:13 UTC
*** Bug 105763 has been marked as a duplicate of this bug. ***
Comment 19 Cor Nouws 2017-02-07 16:51:24 UTC
ugly hack indeed with bug 44282 ;)

On the other hand: how often does one set a space _after_ the item in the TOC?
So not sure if the patch should be reverted right away.
Comment 20 JoNi 2017-02-07 17:14:23 UTC
(In reply to Cor Nouws from comment #19)
> On the other hand: how often does one set a space _after_ the item in the
> TOC?
see bug 105758, comment 0
>> Additional Info:
>> ...
>> The index format I am using is the format recommended 
>> in both The Chicago Manual of Style, and The Oxford Guide to Style.
>>
>> So I would say it is fairly important that this works properly in Writer.

> So not sure if the patch should be reverted right away.
imo, it should be reverted as there is no workaround for this bug.
but bug 44282 as an easy workaround, add a space after the chapter number in the TOC.
Comment 21 Cor Nouws 2017-02-08 14:30:03 UTC
*** Bug 105859 has been marked as a duplicate of this bug. ***
Comment 22 Buovjaga 2017-02-08 15:54:43 UTC
Helmut: please stop changing the fields to wrong content. You keep changing architecture to 64-bit and OS to Windows, even though there are reports/confirmations on 32-bit and Linux.
Comment 23 Ronny Bremer 2017-02-09 12:20:50 UTC
(In reply to Cor Nouws from comment #19)
> ugly hack indeed with bug 44282 ;)
> 
> On the other hand: how often does one set a space _after_ the item in the
> TOC?
> So not sure if the patch should be reverted right away.

In our environment, for every single document. We have spaces directly after the item and before the page number. It is easier to read for the viewer IMHO.
Comment 24 LibreTraining 2017-02-09 20:48:35 UTC
(In reply to Cor Nouws from comment #19)
> ugly hack indeed with bug 44282 ;)
> 
> On the other hand: how often does one set a space _after_ the item in the
> TOC?
> So not sure if the patch should be reverted right away.

Adding a space is not the only trigger of this bug.

In my bug report:
Bug 105758 - Writer 5.3.0.3 Truncates Alphabetical Index Entries

I deleted the [T] (tab) and replaced it with ", " (comma space)
Same problem, truncates last letter.

Just tested with other characters replacing the tab.
- Comma alone - same problem, truncates last letter.
- Underline character alone - same problem, truncates last letter.
- Letter X alone - same problem, truncates last letter.

So this bug affects virtually any change which deletes the tab entry.


Furthermore it makes no sense for the default index format to include this tab.
It would make more sense for the default index format to be what is actually used in professional documents.
Pick up virtually any textbook or technical book on your bookshelf and take a look at the index.
It will most like likely have an index formatted as recommended by The Chicago Manual of Style and/or The Oxford Guide to Style.

Neither of these guides recommends an Index format which looks like a Table of Contents.
It would make more sense for the default Index format in LibreOffice to follow the recommendations of these industry-standard guides - like virtually every book on your bookshelf.
Why should LibreOffice users have to fix this every time they make a new document?
That is just dumb.
Comment 25 LibreTraining 2017-02-09 20:55:53 UTC
Just tested with entering nothing after deleting the tab.
Same issue, truncates last letter.
Comment 26 Cor Nouws 2017-02-09 22:35:07 UTC
(In reply to LibreTraining from comment #24)
> 
> Adding a space is not the only trigger of this bug.

Then I request to immediately revert the patch that caused this problem.
Comment 27 Xisco Faulí 2017-02-10 15:10:25 UTC
*** Bug 105916 has been marked as a duplicate of this bug. ***
Comment 28 Lars Jødal 2017-02-13 08:26:22 UTC
Created attachment 131167 [details]
Example file showing and describing the problem with another character than space

This attachment uses an x instead of a space, partly for visibility (a space is hard to see), partly to demonstrate that the problem is not specific for a space.

The bug may be a regression (I only experienced it myself recently), but de-installing the fresh LO version (5.3.0.3) and instead installing the current still version (5.2.5.1) does NOT make the bug disappear!
Comment 29 Xisco Faulí 2017-02-14 22:40:32 UTC
*** Bug 106003 has been marked as a duplicate of this bug. ***
Comment 30 Stefan Golla 2017-02-15 00:37:38 UTC
(In reply to Xisco Faulí from comment #29)
> *** Bug 106003 has been marked as a duplicate of this bug. ***

OK, So I still urgent repeat the request to kill the last patch, back to the version of 5.2.4, where there not this problem with killing letters, but also, that the TAB-Funktion to set the TAB to the right side by confirming, will be killed, if you put any letter between the "T" and the "#" AND a letter behinde the "#" will also kill the page number!
So this bug make the complete use of the open textfield between all functions of the ToC-formating to non-sense.
So please debug this last patch!
Thanks alot!
Comment 31 Cor Nouws 2017-02-15 08:50:42 UTC
Hi abhilash,

(In reply to abhilash300singh from comment #8)
> I had written that patch thinking( after reading this
> http://opengrok.libreoffice.org/xref/core/sw/inc/tox.hxx#177 )  that case
> TOKEN_TEXT is only hit when the user types something between E# and E. 
> Seems I'm not fully clear on when different cases are hit. Any explanations
> on when these cases are hit will help. I'll take a look again. 

If you have no better solution now, can you please revert the patch shortly?
Comment 32 Xisco Faulí 2017-02-15 10:02:37 UTC
*** Bug 106017 has been marked as a duplicate of this bug. ***
Comment 33 Commit Notification 2017-02-15 11:35:31 UTC
Xisco Fauli committed a patch related to this issue.
It has been pushed to "master":

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

tdf#104315: Revert "tdf#44282 fix missing space...

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 34 Xisco Faulí 2017-02-15 11:38:16 UTC
Commit reverted in master and cherry-picked to 5.3: https://gerrit.libreoffice.org/#/c/34295/
Closing this one as RESOLVED FIXED and reopening bug 44282
Comment 35 Xisco Faulí 2017-02-15 12:54:17 UTC
*** Bug 106005 has been marked as a duplicate of this bug. ***
Comment 36 Commit Notification 2017-02-15 13:26:56 UTC
Xisco Fauli committed a patch related to this issue.
It has been pushed to "libreoffice-5-3":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=05116fb49efa563610f6486d0c3f6216624dcd13&h=libreoffice-5-3

tdf#104315: Revert "tdf#44282 fix missing space...

It will be available in 5.3.1.

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 37 Xisco Faulí 2017-02-16 01:20:02 UTC
*** Bug 106036 has been marked as a duplicate of this bug. ***
Comment 38 Daniel Grigoras 2017-02-16 11:36:30 UTC
(In reply to Commit Notification from comment #36)


I just tested with LibreOfficeDev 5.3.1.0.0+ and the issues has not been resolved. The last characters are still not displayed for Entry upon insertion of a blank space between Entry and Tab stop.
Comment 39 Xisco Faulí 2017-02-16 11:40:30 UTC
(In reply to Darius Daniel Grigoras from comment #38)
> (In reply to Commit Notification from comment #36)
> 
> 
> I just tested with LibreOfficeDev 5.3.1.0.0+ and the issues has not been
> resolved. The last characters are still not displayed for Entry upon
> insertion of a blank space between Entry and Tab sto

Have you used today's build which includes http://cgit.freedesktop.org/libreoffice/core/commit/?id=05116fb49efa563610f6486d0c3f6216624dcd13&h=libreoffice-5-3 ? If so, please open a follow-up ticket and let's keep this one closed as the problematic commit has been reverted.
Comment 40 Aron Budea 2017-02-19 22:33:29 UTC
*** Bug 106092 has been marked as a duplicate of this bug. ***
Comment 41 Xisco Faulí 2017-03-02 11:51:11 UTC
*** Bug 106258 has been marked as a duplicate of this bug. ***