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.
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.
@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.
Oh… I can't edit the original report.
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.
@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.
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.
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
Created attachment 112168 [details] Test file (background of frame should be violet)
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
*** Bug 88146 has been marked as a duplicate of this bug. ***
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?
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.
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
*** Bug 89730 has been marked as a duplicate of this bug. ***
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
@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.
Please make this bug a release blocker for 4.4.2. It silently renders opened files useless if they are saved.
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.
Unfortunately, the problem is still there in 4.4.2.1. Let's hope for 4.4.2.2!
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?
duplicate of bug 86578 already on 4.4. mab *** This bug has been marked as a duplicate of bug 86578 ***
this is not a duplicate of bug 86578 but of bug 90130 *** This bug has been marked as a duplicate of bug 90130 ***
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]