Bug 87369 - FILEOPEN: Frame background colour is changed to white on loading
Summary: FILEOPEN: Frame background colour is changed to white on loading
Status: RESOLVED DUPLICATE of bug 90130
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.4.0.0.beta1
Hardware: All All
: highest blocker
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
: 88146 (view as bug list)
Depends on:
Blocks:
 
Reported: 2014-12-16 16:56 UTC by Paddy Landau
Modified: 2015-12-15 11:03 UTC (History)
9 users (show)

See Also:
Crash report or crash signature:


Attachments
Test file (background of frame should be violet) (8.19 KB, application/vnd.oasis.opendocument.text)
2015-01-13 14:15 UTC, Matthew Francis
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Paddy Landau 2014-12-16 16:56:09 UTC
When saving a document where a frame has a background colour, this colour is changed to white on saving.

How to replicate:

1. Create a new document (or edit an old one).
2. Create a new frame. (As a side note, trying to choose Colour at this point usually doesn't work.)
3. Frame > Area > Fill > Colour > choose any colour other than white.
4. Save the document.
5. Close the document.
6. Re-open the document.

What happens:

* The frame's colour has changed to white (confirmed with Frame > Area).

What should happen:

* The frame retains the chosen colour.

This has been tested on both Windows 7 and Ubuntu 14.04 64-bit with LibreOffice 4.4.0.0.beta2.

This bug is more serious than it sounds, because it can take a tremendous amount of work to keep resetting the colours of several frames in a document. For example, I have one document used for a community, containing nine non-white frames and edited thousands of times (no exaggeration) per year. That potentially would equate to over a million frame fixes over its (so far) ten-year lifespan.
Comment 1 MM 2014-12-16 21:57:02 UTC
Confirmed under mint 17 x64 with 4.4.0.0.beta2 Build ID: be92f32b8f21603a6b7a75dd645f7475bdee519d

Color has changed to white when *loading* the file, not saving.
You can see the correct color if you load it in another, older version.
Comment 2 Paddy Landau 2014-12-17 13:21:51 UTC
@MM Thank you.

I confirm that I have the same results as you, loading with version 4.3.4.1.

I shall edit the original report to reflect this.
Comment 3 Paddy Landau 2014-12-17 13:22:53 UTC
Oh… I can't edit the original report.
Comment 4 MM 2014-12-17 16:14:10 UTC
Load the file saved with 4.4 with 4.3 for example and resave it to another name. Now, if you copy over content.xml from the '4.3' file to the '4.4' file, it can be imported in 4.4 again.
Comment 5 Paddy Landau 2014-12-17 18:20:02 UTC
@MM, I have duplicated what you suggested.

Unfortunately, of course, as soon as you make a change and re-save the document in 4.4, it again loads as white.

The difference between the two content.xml files seems to be the addition in the version 4.4 file of the following line (replace #c5000b with your chosen colour):

draw:fill-color="#c5000b" draw:fill-image-width="0in" draw:fill-image-height="0in"

I don't know enough about .xml files to be able to comment why this should prevent version 4.4 from using the chosen colour. But, the information should at least help the developers to find and fix the bug.
Comment 6 tmacalp 2014-12-31 20:19:55 UTC
This is a serious regression that should not make it into 4.4.0.  I can confirm this behavior in 4.4.0.1 rc.  I'll mark it as a regression and up the importance to high.  If this was regarding a released version, it would warrant an importance of blocker according to the bug prioritization flowchart.
Comment 7 tmacalp 2015-01-12 18:34:41 UTC
I bibisected:

62e81d8a4ea612991512b908f80f3b40230ba9ef is the first bad commit
commit 62e81d8a4ea612991512b908f80f3b40230ba9ef
Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com>
Date:   Thu Nov 6 02:27:20 2014 +0000

    source-hash-d8e21f0400c5ae77e388ef81b7fcad9f65401c65
    
    commit d8e21f0400c5ae77e388ef81b7fcad9f65401c65
    Author:     Stephan Bergmann <sbergman@redhat.com>
    AuthorDate: Tue Sep 30 08:24:10 2014 +0200
    Commit:     Stephan Bergmann <sbergman@redhat.com>
    CommitDate: Tue Sep 30 10:33:25 2014 +0200
    
        compilerplugins: get rid of std::auto_ptr in comment
    
        Change-Id: Ia2b1bc97f3476da7bfbe659e5160cd5c73c01ce5

:100644 100644 5c3813bbffcc1a973d54c24b9344a27004b8e8d4 3c6de89b42d551444e7249b54f84c458f0131f8f M      ccache.log
:100644 100644 603d4f7a782b36e2f744e3f1b7ae0d15f3267ee0 a01b9c064d6d47bf8377eb49bc32be6ba3efd54c M      commitmsg
:100644 100644 04bc02ea6b9a198280636d812dadf526391078a0 bd57af0b2b70f65eeb4e4e24d93e7f3d2dc31736 M      make.log
:040000 040000 b4c02035df8301972581e0df7ca439311ef4d5d2 a9c2ee18b91f9f5f64bde6f0231d616c6678b773 M      opt

$ git bisect log
# bad: [4a3091e95fa263d3e2dd81e56e83996f0bb12287] source-hash-2b5b04e1e62914bf0902dfd7943cdc44499c47a6
# good: [812c4a492375ac47b3557fbb32f5637fc89d60d9] source-hash-dea4a3b9d7182700abeb4dc756a24a9e8dea8474
git bisect start 'latest' 'oldest'
# good: [5d0dfb8e62ae61a240f8313c594d4560e7c8e048] source-hash-0c6cd530de13f80795881f61064f1bf1dcc4ea81
git bisect good 5d0dfb8e62ae61a240f8313c594d4560e7c8e048
# good: [7dfacd0b8bd828331d74c0f79de6e8924bc4e6a5] source-hash-f93ce4f7eb90093d0ea3115d0a1c614612676dbd
git bisect good 7dfacd0b8bd828331d74c0f79de6e8924bc4e6a5
# bad: [a42da134cd542144fca7ba14cce86c2b409fc18a] source-hash-beadebc0f7eb5582fcb8dcb082d19afdf2751876
git bisect bad a42da134cd542144fca7ba14cce86c2b409fc18a
# bad: [5f697ca821720f76105e5539f0408e68a0647481] source-hash-f9695150942341a755a43996d4639eb623d7640b
git bisect bad 5f697ca821720f76105e5539f0408e68a0647481
# bad: [3b00b662438462a4b73b0531ffa6192fc7e72638] source-hash-0a5cd87e591d7f87bfab92716079af719259f143
git bisect bad 3b00b662438462a4b73b0531ffa6192fc7e72638
# good: [b4320c4383b3d61076ac1794797bd3162612889d] source-hash-da21f7da44dc577a08ea3bc210083dc8decf18bc
git bisect good b4320c4383b3d61076ac1794797bd3162612889d
# good: [e1690f3a96306b42e829d63cb23a48e4b90603b5] source-hash-3d394257945f6b0a4bc4b5ea397a3942a59c5d06
git bisect good e1690f3a96306b42e829d63cb23a48e4b90603b5
# bad: [62e81d8a4ea612991512b908f80f3b40230ba9ef] source-hash-d8e21f0400c5ae77e388ef81b7fcad9f65401c65
git bisect bad 62e81d8a4ea612991512b908f80f3b40230ba9ef
# good: [8d288df76cd45312945404c1805ffae2418a27a8] source-hash-26f2da07b1c6074e519d28557a3d1d5518ff6cb4
git bisect good 8d288df76cd45312945404c1805ffae2418a27a8
# first bad commit: [62e81d8a4ea612991512b908f80f3b40230ba9ef] source-hash-d8e21f0400c5ae77e388ef81b7fcad9f65401c65
Comment 8 Matthew Francis 2015-01-13 14:15:02 UTC
Created attachment 112168 [details]
Test file (background of frame should be violet)
Comment 9 Matthew Francis 2015-01-13 14:16:58 UTC
The behaviour seems to have changed as of the below commit.

Adding Cc: to caolanm@redhat.com; Could you take a look at this one? Thanks


commit 5aa360cae0383f270c12708e7e94179a7fde6711
Author: Caolán McNamara <caolanm@redhat.com>
Date:   Mon Sep 29 16:25:27 2014 +0100

    Resolves: fdo#80468 and fdo#81223 image/frame backgrounds wrong
    
    writer has code to fill in missing new properties from the old properties
    if they exist. But xmloff is stripping them out before they get there.
    
    Don't strip them out, and add in a missing check for one of the
    archaic bg colors and add a regression test for fdo#81223
    
    Change-Id: I9a541a9bee0a01c90f2c33383f1144ecd8b0bfff
Comment 10 tmacalp 2015-01-28 05:50:00 UTC
*** Bug 88146 has been marked as a duplicate of this bug. ***
Comment 11 Paddy Landau 2015-01-30 11:56:42 UTC
I have today installed the just-released version 4.4.0.


This bug is still present.


It is a critical show-stopper for me; I cannot use version 4.4 until this is fixed (as per my original post).

I am sure that this will affect many people.

This bug has still not been assigned. Is there any way to have it looked at by the developers?
Comment 12 Paddy Landau 2015-02-26 13:41:43 UTC
This is still present in 4.4.1.2.

Is there any way to have this looked at, please? It's only three months before support for 4.3 ends, so this needs to fixed before then.
Comment 13 Alessandro Fardin 2015-02-27 16:28:08 UTC
I can Confirm.

I've got the same issue, as I open documents created with libreoffice 4.3 and also new documents created with 4.4.

I'm running on ubuntu 12.04
Comment 14 MM 2015-03-02 23:49:43 UTC
*** Bug 89730 has been marked as a duplicate of this bug. ***
Comment 15 PeterSHarris 2015-03-05 05:16:51 UTC
This bug occurs in 4.4.1 fresh and occurred in other recent releases.

Don't know whether frame background colour is not saved with document or not retrieved upon file open.

Regards
Comment 16 Paddy Landau 2015-03-05 15:37:38 UTC
@PeterSHarris, the information is initially saved but then incorrectly loaded, and subsequently incorrectly saved. Loading from version 4.3 correctly loads it, showing how it has been saved.
Comment 17 Rico Tzschichholz 2015-03-10 11:17:43 UTC
Please make this bug a release blocker for 4.4.2. It silently renders opened files useless if they are saved.
Comment 18 Paddy Landau 2015-03-10 11:41:21 UTC
According to the following flowchart:

https://wiki.documentfoundation.org/images/0/06/Prioritizing_Bugs_Flowchart.jpg

This should be Importance: Highest + Blocker.

I have made the changes.
Comment 19 Andy 2015-03-14 11:47:30 UTC
Unfortunately, the problem is still there in 4.4.2.1.
Let's hope for 4.4.2.2!
Comment 20 Andy 2015-03-15 22:11:42 UTC
While desperately experimenting with frame colors, I discovered that, while Any color set is transformed into white when saving the file in ODT format, if you set the area of the frame as transparent, it actually stays white, and you cannot see anything (E.G. other objects) behind the frame even if its properties state that it has no filling.
Actually, I am not sure whether this is regression or a bug, since I do not remember to have used this option in the past. Should I open another ticket?
Comment 21 V Stuart Foote 2015-03-15 23:25:17 UTC
duplicate of bug 86578 already on 4.4. mab

*** This bug has been marked as a duplicate of bug 86578 ***
Comment 22 Michael Stahl (CIB) 2015-04-14 15:57:10 UTC
this is not a duplicate of bug 86578 but of bug 90130

*** This bug has been marked as a duplicate of bug 90130 ***
Comment 23 Robinson Tryon (qubit) 2015-12-15 11:03:07 UTC
Migrating Whiteboard tags to Keywords: (bibisected)
[NinjaEdit]