Created attachment 123093 [details] A screenshot showing the problem I have a table in Writer in which I have marked the colour of certain cells. I have done this without first selecting the entire cell. That is: I have just left-clicked on the cell and chosen a background colour. The result has always been (and still is) that the colour is applied to the cell, but with a small white border. If the cell is a square it looks like a smaller colured square with a white border within the cell. Up until I upgraded to LibreOffice 5.1.0.3 (from 4.3, I think), I have been able to change the colour of this small box, simply by clicking on the cell and choosing a new background colour. This is STILL possible in 5.1.0.3, but when I save, the new formatting is NOT saved. If I save, close the document and reopen it, the old colour is back. I cannot remove the colour in these boxes. If I mark them and choose to remove colour all together, nothing happens, and if I choose a different colour, it will not be saved as described above. Furthermore, the formatting is applied to new rows inserted below a row with a coloured cell in the table, so if I have a row with a green box in one cell, and I insert a new row below this row, the cell below the cell with the green box will ALSO have a green box. If I mark an entire cell and choose to apply background colour, everything works fine. The colour is saved etc. This, however, doesn't help if I want to change the colour of the smaller coloured box (that is: If I have a cell with a green box with a white border, marking the entire cell and changing the background colour to for instance red, will only change the colour of the white border to red, not the colour of the smaller green box in front of it).
Added: I forgot to mention, that the file format, I try to save in, is ".doc" (Word 97-2003). If I try to save in ODT format, changing the color works just fine, and can be changed/saved - it does, however, mean that ALL the colour information in all the other cells is lost when saving from DOC to ODT (so I will have to manually reapply all color).
(In reply to Jakob from comment #1) > Added: I forgot to mention, that the file format, I try to save in, is > ".doc" (Word 97-2003). Thanks for filing and the addition, Jakob. I think the problem is that ms Doc does not support both and background and highlighting. See some info here. http://zolnaitamas.blogspot.nl/2015/03/word-compatible-text-highlighting-in.html > If I try to save in ODT format, changing the color works just fine, and can > be changed/saved - it does, however, mean that ALL the colour information in > all the other cells is lost when saving from DOC to ODT (so I will have to > manually reapply all color). Maybe some smart automation (macro) could help.. I think we should resolve your report to NotOurBug, or WorksForMe?
I have now just changed the document to ODT format and have copied the different colours by hand (all 46 pages). As I wrote, the colouring of the boxes worked fine in LibreOffice 4.3. The issue have only appeared after I upgraded. The document was originally also created in LibreOffice and has never been opened in Word (I only saved in DOC format in case I would have to send the document to someone who could not open ODT documents sometime in the future), so it definitely seems to be something that has been changed between LibreOffice 4.3 and 5.1.0.3. NotOurBug seems a little like stretching the truth, as does WorksForMe. On the other hand, I have found a workaround by changing to ODT and copying the colours, so the issue is not a big deal for me anymore :)
(In reply to Jakob from comment #3) > ... > future), so it definitely seems to be something that has been changed > between LibreOffice 4.3 and 5.1.0.3. Definitely. A change that influences how things are saved in .doc. Did you try to get your head around the linked article? > NotOurBug seems a little like stretching the truth, as does WorksForMe. maybe ... > On the other hand, I have found a workaround by changing to ODT and copying > the colours, so the issue is not a big deal for me anymore :) That's fine. Still it's good to find out whether this is a bug, or a change in filter behavior to improve compatibility, and that also has a downside affect on certain habits from the past, but that maybe can be solved by doing something different now (also in .doc.)
Confirmed. Works in 4.3.0.1, broken in 4.4.5.2 Win 7 Pro 64-bit, Version: 5.1.0.3 (x64) Build ID: 5e3e00a007d9b3b6efb6797a8b8e57b51ab1f737 CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; Locale: fi-FI (fi_FI) Version: 5.2.0.0.alpha0+ Build ID: b89feb8018bf3610faf01e73995d576f6566e20b CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; TinderBox: Win-x86@39, Branch:master, Time: 2016-03-07_03:36:17 Locale: fi-FI (fi_FI)
git bisect log # bad: [489ffd1df414698b6cea9ab03bf6f663b8b5af7e] source-hash-3f94c9e9ddfd807b449f3bb9b232cf2041fa12d2 # good: [8aa9fc9a0c92172593d6cd97662116a965db229d] source-hash-dea4a3b9d7182700abeb4dc756a24a9e8dea8474 git bisect start 'latest' 'oldest' # bad: [897913acd244cb6a5d2f4c2da1d625d9b978edb6] source-hash-ac57362b23859591c088e36b7218f4a606dcf3bb git bisect bad 897913acd244cb6a5d2f4c2da1d625d9b978edb6 # bad: [dc97f44745f96315fb6c5480705bb5d595d39c6c] source-hash-01c8962f281887db59e581906b89d027a994b52a git bisect bad dc97f44745f96315fb6c5480705bb5d595d39c6c # good: [a5a39af2ec486b10b26d6373f58a9b59142106c4] source-hash-a595879302e26a616131aa0cab5de31bb287b37d git bisect good a5a39af2ec486b10b26d6373f58a9b59142106c4 # bad: [54a9a5df46b192bd5b9bd44702ef3bffd5730523] source-hash-e2f1fffc81896c0773a18e468635056710927d8f git bisect bad 54a9a5df46b192bd5b9bd44702ef3bffd5730523 # bad: [54a9a5df46b192bd5b9bd44702ef3bffd5730523] source-hash-e2f1fffc81896c0773a18e468635056710927d8f git bisect bad 54a9a5df46b192bd5b9bd44702ef3bffd5730523 # bad: [f1cbe8b4bb7351ee7ca566e6c29229948fcac423] source-hash-9263b101c39172cbcf04189c515bca80cb15f3aa git bisect bad f1cbe8b4bb7351ee7ca566e6c29229948fcac423 # good: [22dc367922c4141d54b8130ee266e934a6ae6e5c] source-hash-4523dd0544d762961435429167e41a0834b60cea git bisect good 22dc367922c4141d54b8130ee266e934a6ae6e5c # good: [112921daada24f4799be40fc4e9c53964fdf46b3] source-hash-dc93074f71f91efd8a615ad8f1a5289deb210b75 git bisect good 112921daada24f4799be40fc4e9c53964fdf46b3 # good: [ab0483eaee7e89e0784fa25b6a3f7cd6d710def3] source-hash-611b419562dbde945d532ce27d7233be5d55fda1 git bisect good ab0483eaee7e89e0784fa25b6a3f7cd6d710def3 # bad: [28f12c293dbe6db80b8981ba7b91e27f208c78df] source-hash-33e9d408aa2c0a9b86c5daaed0e15d86f6c599dc git bisect bad 28f12c293dbe6db80b8981ba7b91e27f208c78df # bad: [24981fd6f84d800925f45d04c4de4923ea3bf375] source-hash-b398f8157699030061dde88d967364bedd5b2a52 git bisect bad 24981fd6f84d800925f45d04c4de4923ea3bf375 # first bad commit: [24981fd6f84d800925f45d04c4de4923ea3bf375] source-hash-b398f8157699030061dde88d967364bedd5b2a52 One of these commits: 2014-07-01 -Werror,-Wtautological-constant-out-of-range-compare Stephan Bergmann 1 -1/+1 2014-07-01 android: LibreOfficeKit needs the path to program/ as the starting point. Jan Holesovsky 1 -1/+14 2014-07-01 getSvxBrushItemFromSourceSet: add fix for JunitTest_sw_complex Miklos Vajna 1 -1/+9 2014-07-01 SwXPageStyle::GetPropertyValues_Impl: lost FN_UNO_HEADER/FOOTER_FIRST Miklos Vajna 1 -0/+4 2014-07-01 SwXAutoStyle::GetPropertyValues_Impl: fix handling of CharAutoStyleName Miklos Vajna 1 -1/+2 2014-07-01 getSvxBrushItemFromSourceSet: let XFILL_NONE result in COL_AUTO Miklos Vajna 1 -4/+1 2014-07-01 SwXPageStyle: fix FirstIsShared handling Miklos Vajna 1 -5/+5 2014-07-01 Remove stray fprintf Miklos Vajna 1 -2/+0 2014-07-01 fix tests Caolán McNamara 1 -2/+9 2014-07-01 Resolves: #i125045# For XMLPropertyMapper using TEXT_PROP_MAP_SHAPE_PARA... Armin Le Grand 2 -28/+34 2014-07-01 Related: #i124638# Corrected relationship between DrawModel and... Armin Le Grand 43 -149/+151 2014-07-01 Related: #i124638# Corrected paints of Writer Frames... Armin Le Grand 1 -6/+11 2014-07-01 hook up new drawing support to .uis Caolán McNamara 5 -17/+211 2014-07-01 Related: #i124638# Second step of DrawingLayer FillAttributes... Armin Le Grand 105 -2607/+5294 2014-07-01 writerfilter/source: change directory dependencies to .../ooxml/.dir Douglas Mencken 1 -3/+3 2014-07-01 coverity#735397 dead code Norbert Thiebaud 1 -5/+1 http://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=611b419562dbde945d532ce27d7233be5d55fda1..b398f8157699030061dde88d967364bedd5b2a52 Miklos, please could you take a look? Thanks
** 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
The bug is still present. I have added info below (parts are in Danish as the version I use is Danish): Version: 6.0.6.2 (x64) Bygge-ID: 0c292870b25a325b5ed35f6b45599d2ea4458e77 CPU-tråde: 8; Styresystem: Windows 10.0; Gengiver af brugergrænseflade: Standard; Lokalitet: da-DK (da_DK); Calc: group As Buovjaga earlier stated, the bug appeared around version 4.4.5.2 I am not personally troubled by the bug anymore, as I have converted the document to ODT and do not use the DOC version anymore.
Hi Jakob, this issue was introduced in the same range of commits than bug 126013, which is fixed in LibreOffice 6.3.3. Could you please try again this issue with version 6.3.3 ?
Hi I have tested, and the problem is (in some sense) solved. Before, I could left-click a cell and when I chose a colour, the cell would get this colour, but with a small white border. Now, when I left-click and choose a colour, the entire frame gets coloured (without the white border), just as it would if I had marked the entire cell and chosen a colour in older versions. I have tested in a document with coloured cells with borders (from an older version) and in v. 6.3.3.2 it is not possible to change or remove the colour in these cells anymore. This is not a big issue for me, however, since the new behaviour in v. 6.3.3.2 (colouring the entire cell regardles of whether I have just lef-clicked the cell or I have marked the entire cell) is more appropriate and correct behaviour in my opinion. It could affect people with documents as mine (with coloured cells with borders), though, making it impossible for them to change the colour of those cells, so the best solution would be to make LibreOffice in some way clear the colouring of the cells with borders before applying the new colour (that is: If I have a cell with a red box and white border, and I choose a green background colour, LibreOffice should remove any colour formatting of the cell - the red colour - before applying the green colour. Right now it is impossible to remove the red colour, and the green colour is only visible in the border around the red colour). In any case, I think the behaviour where LibreOffice made the coloured box with the border must have been a bug to begin with, so the new behaviour is correct, whether it makes it impossible to change the colour of cells coloured as described above or not.
Ok, let's close