Problem description: Steps to reproduce: [1] Open new text document. [2] Choose a "nice" colour for the background of fields (Tools > Options > LibreOffice > Appearance > Custom Colors > Field shadings) [3] Insert two lines with bullets. [4] Position the cursor in front of a bullet (with arrow key or by mouse click). The backgrounds of both bullets are now displayed with the chosen colour of step 2. [5] Move the cursor back with an arrow key. The background colour for fields disappears. The behaviour is equal, if you position the cursor in front of numbering digits or chapter numbers. Expected behaviour: No change of background colours. Additional comments: (a) If you use several lists (bullets and/or numbered) in a greater document, not all bullets or digits change their background colour. The conditions for this behaviour I did not check. (b) I am not sure if it is necessary, that the cursor can be positioned in front of numbers and bullets. For example if you press the home key in order to jump to the beginning of a line, the cursor is not positioned in front of the bullet/number, but in front the first character after the bullet/number. (c) It has been argued, that numbers/bullets are also a kind of fields. But if this is intended the background of numbers/bullets should always be displayed in the colour of fields. This should not depend on the cursor position. Browser: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20100101 Firefox/14.0.1
See also bug 52526 and bug 52527.
Another aspect, go on with: [6] Mark the whole text (Cntr+A). Display Styles (F11). Assign a different character style to the whole text, e.g. Emphasis. [7] Display only Applied Styles. Displayed character styles: “Default” and “Emphasis”. Expected behaviour: Only “Emphasis” should be displayed. [8] Position the cursor again in front of a bullet. Displayed current character style: Default. Expected: Emphasis.
the change of the background color of the bullet is reproducible with LO 4.0.0.3 (Win7 Home, 64bit), when positioning the cursor before the bullet
I think Bug 69697 is probably a duplicate of this but I suggest to check it's nice testcase.
I think this bug (like bug 52526) is an enhancement request as this option has never existed. The changes I have indicated in that bug (https://bugs.freedesktop.org/show_bug.cgi?id=52526#c4) to the summary, version, importance, and severity could all be made here also.
(In reply to comment #5) > importance Sorry. Ignore my reference to the importance, as I did not change this in the indicated bug.
** 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 on a currently supported version of LibreOffice (4.4.2 or later) https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) 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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-05-02
Bug still exists in version 4.4.3 with Win7. Bug also exists in version 3.3.0, hence version changed to "Inherited...".
** 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 on a currently supported version of LibreOffice (5.1.5 or 5.2.1 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) 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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20160920
Bug still exists in version 5.2.1 with Win7.
** 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 checked again with version 6.0.4 (64 bit Win10). Bug still exists. Change respective to initial report: Step [2]: The name of the option category changed from "Appearance" to "Applicatin Colors". (In reply to Harald Koester from comment #0) > (b) I am not sure if it is necessary, that the cursor can be positioned in > front of numbers and bullets. For example if you press the home key in order > to jump to the beginning of a line, the cursor is not positioned in front of > the bullet/number, but in front the first character after the bullet/number. Meanwhile I think that it should be possible to position the cursor in front of bullets and numbers in all cases, in order to select text with and without numbers. Then you can copy (Ctrl+C, Ctrl+V) the text with and without numbers to another application. See bug report 49076.
See comment 12.
Dear Harald Koester, 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 still exists in version 6.2.4 (64 bit) with Win10.
Dear Harald Koester, 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 https://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
Dear Harald Koester, 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 https://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://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Bullets are still shaded when cursor in front of them in: Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 3be785e088cc0aa726509cf6b52b1d3b03817172 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded But I think it makes sense to keep it like that: applying some direct formatting (e.g. font colour) will affects all bullets in the the list, therefore it's important visual feedback for the users and should remain – but the validity of using the field colour for that is debatable. Heiko, what do you think?
Created attachment 192321 [details] sample lists in ODT One issue I noticed is that the shading doesn't necessarily appear on all the bullets that are affected by a direct formatting change. In the attached sample, move the cursor before a bullet in list 4 and change the font colour: only List 4's bullets are shaded, but the formatting is applied to all bullets of that same level.
(In reply to Harald Koester from comment #0) > (a) If you use several lists (bullets and/or numbered) in a greater > document, not all bullets or digits change their background colour. The items that belong to the same list become shaded (test with restart list and add to list, and double check the list id at the style inspector). > (c) It has been argued, that numbers/bullets are also a kind of fields. But > if this is intended the background of numbers/bullets should always be > displayed in the colour of fields. You would loose the ability to identify what items belong to the same list. (In reply to Stéphane Guillou (stragu) from comment #19) > the validity of using the field colour for that is debatable. It's an indicator for what is being automatically generated. I see no benefit using a different color. => NAB