Problem description: Steps in order 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 button or by mouse click). The background of both bullets is now displayed with the chosen colour of step 2. Expected behaviour: No change of colours. The proceeding for numbering digits is equal. If you use several lists (bullets and/or numbered) in a greater document, not all bullets or digits change their background colour. The conditions of this behaviour I did not check. Formatting marks always get the background colour for fields, when they are inserted (Insert > Formatting Marks). Expected behaviour: Use of a fixed colour for background of formatting marks. Browser: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2.26) Gecko/20120128 Firefox/3.6.26
Also numbers of chapter headings are marked in the background colour of fields if the cursor is set in front of the number.
Another problem in this relation: Check boxes disappear. Do this: [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 a heading with chapter number. [4] Insert a check box under heading. [5] Set design mode to "off". [6] Position the cursor with arrow buttons in front of the heading number. The heading number is marked in the background colour of fields AND the check box disappears!! If you use the mouse to position the cursor, the box does not disappear, only the heading number is marked. [7] Scroll with mouse wheel and the check box is back again. If other form controls disappear too, I did not check. In this relation I ask myself if it is necessary, that the cursor can be positioned in front of numbers and bullets. I think not, but I don't know all use cases.
Another item, which is marked incorrectly with the colour of fields. Do this: [1] Open new text document. [2] Display nonprinting Characters. [3] Choose a "nice" colour for the background of fields (Tools > Options > LibreOffice > Appearance > Custom Colors > Field shadings) [4] Type in a heading. [5] Insert a Table of Contents: Insert > Indexes and Tables > Indexes and Tables... > Tab Index/Table > OK. The following is inserted: 1. Line: "Table of Contents", the background colour is grey. OK. 2. Line: Name of Heading (background colour is grey, OK), dotted line up to the page number (background ground colour is displayed in the colour of fields, BUG!!), page number (background colour is grey, OK) [6] Switch off the view of nonprinting characters. Now the background colour of the dotted line is also grey, OK.
Thanks for bugreport Please, attach documents that demonstrate bugs, described in comment 2 and comment 3
Created attachment 62097 [details] Demonstration file Open text document and follow the instructions inside the document.
Thanks for attachment Initial description and comment 1: why it is a bug? Comment 2, using attachment: reproducible in 3.3.4 and 3.5.3 on Fedora 64 bit (on windows not tested). Line with checkbox disappears. Even if color of fields not changed. Please, create separate bugreport for this bug (developers dislike bugreports with much text like this). Comment 3: can not reproduce in 3.5.3 on Fedora 64 bit. May be I do something wrong. Please, attach screenshot of this bug.
Created attachment 63459 [details] Screen shot to comment 3, non-printing characters not displayed
Created attachment 63460 [details] Screen shot to comment 3, non-printing characters displayed
To initial description and comment 1: In my Opinion bullets, numbering digits, formatting marks and chapter numbers are not fields. So the option for field shadings should never used for this items.
To comment 2: I wrote a new bug report according the disappearance of the check box. See bug 51240.
Sorry, the bug number mentioned in my last comment is wrong. Correct is bug 51420.
Thanks for attachment and additional explanations > In my Opinion bullets, numbering digits, formatting marks and chapter numbers > are not fields. As I can see, from LO point of view, these things are fields. Just automatically added. They are automatically recalculated as other fields. IMHO internally they are also fields. From user point they are not fields because not inserted manually. May be separating one sort of fields from other will take much resources from developers because will needed reworking huge amount of internals of LO. And will added many regressions. What about attached screenshots and comment 3 : reproduced in 3.5.4, but it is the same thing as in comment 1 We may change this bug report to functionality request with name something like "Separate automatically added fields and manually added"
Hi Sasha, I agree with you, that "these things" are treated somehow as fields. But there are differences, with one exception they are not _always_ marked as fields: (1) Bullets: only if cursor is positioned in front of bullet (2) Numbering digits: only if cursor is positioned in front of digit (3) Chapter numbers: only if cursor is positioned in front of chapter number (4) Dotted lines in Tables of Contents: only if nonprinting characters are displayed (5) Formatting marks: always marked, hence probably internally treated as fields Especially hence these differences I am still the opinion, that this behaviour should be assessed as a bug and not as a functionality request.
Thanks for additional investigating > Especially hence these differences I am still the opinion, that this behaviour > should be assessed as a bug and not as a functionality request. I agree. But as separate bugreport.
I split this bug into 3 new reports: see bug 52525, bug 52526, bug 52527. Hence this report can be closed (NOTABUG ?).
Marked INVALID as you said individual reports have been opened. In general we don't like META bugs as they are hard to track correctly or make individual updates to (ie. we fix one part and the status doesn't change because entire bug isn't fixed). Thanks for opening individual bugs, helps us a lot