Created attachment 99972 [details] Sample file Platform: Windows 7 64-Bit LibreOffice Version: 4.1.6.2 / Build ID: 40ff705089295be5be0aae9b15123f687c05b0a Steps to reproduce the issue: 1. Start a new document 2. Start a bulleted list 3. Type various bullet points, indenting some of them 4. Highlight some of the indented bullet points 5. Save the file as a .doc file 6. Close the file 7. Re-open the file 8. Issue: All of the bullets are now highlighted, and no matter what you do, you can't unhighlight the the bullets, though you can unhighlight the text. A similar issue also happened where the only difference was that I was applying a strikethrough style to the text instead of doing highlighting. Sample attached.
Created attachment 99973 [details] Another sample
Confirmed in Linux Mint in the latest releases from 4.0 to 4.2 and 4.3 beta. This is an fileopen regression issue as opening any of the attached .doc files opens correctly in word 2010 and LibO 3.6.
bibisected: 56260020c5caba00fbd063db5554b452c06116dc is the first bad commit commit 56260020c5caba00fbd063db5554b452c06116dc Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com> Date: Wed Oct 16 14:50:19 2013 +0000 source-hash-34847f1cf7538c333e9b8700eb4012ae358644a6 commit 34847f1cf7538c333e9b8700eb4012ae358644a6 Author: Kohei Yoshida <kohei.yoshida@gmail.com> AuthorDate: Tue Nov 6 19:17:19 2012 -0500 Commit: Kohei Yoshida <kohei.yoshida@gmail.com> CommitDate: Thu Mar 14 15:35:48 2013 -0400 Re-order the header includes. Make sure column.hxx comes first. Change-Id: I9f93724c4e0b565a9148d0893feda9e82109bff7 :100644 100644 34b251be3d2dc267e2c4b31bf4ade889be54ebd3 a476eec2644ce3d840a3525e60685c10b546a0b1 M ccache.log :100644 100644 b8dc7ff128d9a6772510f291499d3e5f8034e4cf 989a6f8490d3dc9b6552faaa5d3338ef11d96ca2 M commitmsg :100644 100644 75414764833c884979140a22c1fc3f8888a33e78 c3034c36e1045c28850073be1b5eeeab7948599e M dev-install.log :100644 100644 3a778b46f34f3bcf0d3c70c3479270986888f4c9 75d1590884ea160e3916623015bf2d8e8f3f4d63 M make.log :040000 040000 15d374b168b90165da4d70957e5ac1da58e05d89 82cb1a6aa93c11182f124401ee3b61d154ac25e3 M opt # bad: [423a84c4f7068853974887d98442bc2a2d0cc91b] source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e # good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932 git bisect start 'latest' 'oldest' # bad: [e02439a3d6297a1f5334fa558ddec5ef4212c574] source-hash-6b8393474974d2af7a2cb3c47b3d5c081b550bdb git bisect bad e02439a3d6297a1f5334fa558ddec5ef4212c574 # good: [8f4aeaad2f65d656328a451154142bb82efa4327] source-hash-1885266f274575327cdeee9852945a3e91f32f15 git bisect good 8f4aeaad2f65d656328a451154142bb82efa4327 # good: [9995fae0d8a24ce31bcb5e9cd0459b69cfbf7a02] source-hash-8600bc24bbc9029e92bea6102bff2921bc10b33e git bisect good 9995fae0d8a24ce31bcb5e9cd0459b69cfbf7a02 # bad: [8ad82bc1416a07501651e8d96fe268e47d3931d3] source-hash-13821254f88d2c5488fba9fe6393dcf4ae810db4 git bisect bad 8ad82bc1416a07501651e8d96fe268e47d3931d3 # bad: [238338bc4111eb82429ea47384d4012bcd7cdc3e] source-hash-b6ba04639b9922f6717f79ac4be215e09691d7a9 git bisect bad 238338bc4111eb82429ea47384d4012bcd7cdc3e # good: [89dc8a802d1625e0efd88ba0fb720b22be87f3f0] source-hash-da03bb1ee6a69d2f4fef4c3ca0adc0ba9588bd19 git bisect good 89dc8a802d1625e0efd88ba0fb720b22be87f3f0 # good: [4d8d18a8c871d6803af99b706f780eb6e65c7a5d] source-hash-d4779887636fa9ab5b477f3436bcd3728a3e30ba git bisect good 4d8d18a8c871d6803af99b706f780eb6e65c7a5d # bad: [ec6ba885d9d4142060cebdef210d26f0b2ef5045] source-hash-1ce6d6d4133865d9616e12228be2c04cbba1976c git bisect bad ec6ba885d9d4142060cebdef210d26f0b2ef5045 # bad: [d42e14f46fbe1bfc716dc90d28001a0e32afa3d5] source-hash-82b6c4884d7b2fbb3d45980785cebba7a159fb10 git bisect bad d42e14f46fbe1bfc716dc90d28001a0e32afa3d5 # bad: [56260020c5caba00fbd063db5554b452c06116dc] source-hash-34847f1cf7538c333e9b8700eb4012ae358644a6 git bisect bad 56260020c5caba00fbd063db5554b452c06116dc # first bad commit: [56260020c5caba00fbd063db5554b452c06116dc] source-hash-34847f1cf7538c333e9b8700eb4012ae358644a6
Regression introduced by 1c22545edf9085b9f2656ca92781158b6b123db3. I forced SwTxtNode::TryCharSetExpandToNum -http://opengrok.libreoffice.org/xref/core/sw/source/core/txtnode/thints.cxx#1787 to return false and I couldn't reproduce the issue so I guess this is a good point to start the investigation.
Created attachment 101285 [details] Yet Another sample
I have the same issue. See example file 'Yet Another Sample'.
Actually, the work-around I found, is to select the whole series of lines with bullet points, click the bullets icon to withdraw the bullets and then click it again to add new bullets, which are not highllighted this time.
interesting issue :) / :\
FWIW I think that this is a duplicate but no clue where the other one is
*** Bug 83964 has been marked as a duplicate of this bug. ***
(This is an automated message.) It seems that the commit that caused this regression was identified. (Or at least a commit is suspected as the offending one.) Thus setting keyword "bisected".
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]
adding filt:doc keyword.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
*** Bug 108518 has been marked as a duplicate of this bug. ***
If you look at the numbering list WW8Num1, you will see that level1 is assigned to use character style WW8Num1z0. That character style has a highlight colour, and removing it from the character style "fixes" the bullet point as expected. So from what we can see in the UI, things seem to be correct. So then the focus turns to the reproduce-from-scratch steps from comment 0, which somehow got converted into character style formatting. But I can't reproduce that in master or in 5.2 (from 2017). So, then the focus turns to how MS Word imports these documents. In the original file, the yellow bullet background is not seen in Word 2003, but in the files that LO round-trips, the background is seen. Similarly, 9037 - italics-in-para-causes-italic-numbered-list.doc from bug 108518 is not italicized in Word 2003, but is italicized on a round-tripped file. (That is a long way of coming to the same conclusion as comment 2 :-)
The proposed patch in bug 108518 fixes "Test File.doc" from comment 0 and "Test doc.doc" from comment 1.
Fixed in 7.3 as suggested in comment 17. Also fixes duplicate bug 83964 comment 5's "Ochrama2.doc".