Bug 45582 - [METABUG] VIEWING: Background Colour of Different Items are Marked Incorrectly with the Background Colour of Fields
Summary: [METABUG] VIEWING: Background Colour of Different Items are Marked Incorrectl...
Status: RESOLVED INVALID
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.4.5 release
Hardware: Other All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords:
Depends on:
Blocks:
 
Reported: 2012-02-03 03:33 UTC by Harald Koester
Modified: 2012-09-07 15:39 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
Demonstration file (15.49 KB, application/vnd.oasis.opendocument.text)
2012-05-25 04:17 UTC, Harald Koester
Details
Screen shot to comment 3, non-printing characters not displayed (12.24 KB, image/png)
2012-06-25 11:04 UTC, Harald Koester
Details
Screen shot to comment 3, non-printing characters displayed (13.36 KB, image/png)
2012-06-25 11:05 UTC, Harald Koester
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Harald Koester 2012-02-03 03:33:58 UTC
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
Comment 1 Harald Koester 2012-02-08 00:55:38 UTC
Also numbers of chapter headings are marked in the background colour of fields if the cursor is set in front of the number.
Comment 2 Harald Koester 2012-02-08 01:59:48 UTC
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.
Comment 3 Harald Koester 2012-02-14 02:42:45 UTC
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.
Comment 4 sasha.libreoffice 2012-05-14 07:56:52 UTC
Thanks for bugreport
Please, attach documents that demonstrate bugs, described in comment 2 and comment 3
Comment 5 Harald Koester 2012-05-25 04:17:43 UTC
Created attachment 62097 [details]
Demonstration file

Open text document and follow the instructions inside the document.
Comment 6 sasha.libreoffice 2012-05-25 05:13:26 UTC
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.
Comment 7 Harald Koester 2012-06-25 11:04:24 UTC
Created attachment 63459 [details]
Screen shot to comment 3, non-printing characters not displayed
Comment 8 Harald Koester 2012-06-25 11:05:47 UTC
Created attachment 63460 [details]
Screen shot to comment 3, non-printing characters displayed
Comment 9 Harald Koester 2012-06-25 11:07:19 UTC
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.
Comment 10 Harald Koester 2012-06-25 12:30:20 UTC
To comment 2:
I wrote a new bug report according the disappearance of the check box. See bug 51240.
Comment 11 Harald Koester 2012-06-25 12:32:07 UTC
Sorry, the bug number mentioned in my last comment is wrong. Correct is bug 51420.
Comment 12 sasha.libreoffice 2012-06-26 00:07:46 UTC
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"
Comment 13 Harald Koester 2012-07-03 01:21:50 UTC
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.
Comment 14 sasha.libreoffice 2012-07-06 04:20:09 UTC
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.
Comment 15 Harald Koester 2012-07-26 09:59:15 UTC
I split this bug into 3 new reports: see bug 52525, bug 52526, bug 52527.
Hence this report can be closed (NOTABUG ?).
Comment 16 Joel Madero 2012-09-07 15:39:54 UTC
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