Bug 116758 - background color of frame is missing
Summary: background color of frame is missing
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected)
4.4 all versions
Hardware: All All
: medium normal
Assignee: Not Assigned
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Regressions-alg_writerframes
  Show dependency treegraph
Reported: 2018-04-02 17:01 UTC by Regina Henschel
Modified: 2021-03-18 09:25 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:

missing yellow background of frame (5.64 KB, application/vnd.oasis.opendocument.text)
2018-04-02 17:01 UTC, Regina Henschel

Note You need to log in before you can comment on or make changes to this bug.
Description Regina Henschel 2018-04-02 17:01:24 UTC
Created attachment 141037 [details]
missing yellow background of frame

The attached document has been generated by Word 2016. The frame should have a yellow background. You see it, if you open the document in Word, or look into the file source, where you find fo:background-color="#ffff00".

In addition the frame position is different, but that is another issue.

It was OK in Version (Build ID: 84102822e3d61eb989ddd325abf1ac077904985)

It fails in Version:
Build ID: 40b1e8266e47792d354cd457c652bfb0f0a21e69
TinderBox: Win-x86@62-TDF, Branch:MASTER, Time: 2015-02-11_00:13:43
Locale: de_DE

There had been some fixes in regard to background-color, therefore I don't know whether it was OK in between and fails now again.
Comment 1 Buovjaga 2018-04-02 17:36:02 UTC

Arch Linux 64-bit
Build ID: 6acda2a36c9025e0d3fe94d6ca8788ab60c3203e
CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: kde4; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group
Built on April 2nd 2018

Colour is there in
Arch Linux 64-bit
Version (Build ID: e183d5b)
Comment 2 Xavier Van Wijmeersch 2018-04-02 19:10:50 UTC
confirm with

Build ID: e80a0e0fd1875e1696614d24c32df0f95f03deb2
CPU Threads: 8; OS Version: Linux 4.14; UI Render: default; VCL: kde4; Layout Engine: new; 
Locale: nl-BE (en_US.UTF-8); Calc: group

Build ID: e0cdb1e50b77b9a7e93904dd7af0e914a6432abd
CPU threads: 8; OS: Linux 4.14; UI render: default; VCL: kde4; 
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:libreoffice-5-4, Time: 2018-03-28_07:55:10
Locale: nl-BE (en_US.UTF-8); Calc: group

Build ID: 4cb868abaf789afe3f2b4bc65454c21c08666a78
CPU threads: 8; OS: Linux 4.14; UI render: default; VCL: kde4; 
Locale: nl-BE (en_US.UTF-8); Calc: group
Comment 3 Xisco Faulí 2018-04-03 12:09:46 UTC
Regression introduced by 6e61ecd09679a66060f932835622821d39e92f01, which is the same commit as in bug 85283.
I think we can close it as dupe.
Adding it to the metabug as well...

*** This bug has been marked as a duplicate of bug 85283 ***
Comment 4 Justin L 2019-01-14 15:50:57 UTC
Definitely not a duplicate. This is importing problems and bug 85283 is about .doc importing, while this one is about ODT importing.
Comment 5 Xisco Faulí 2019-11-03 20:53:51 UTC
Still reproducible in

Build ID: 2d0a4182712673d8f7a5abe919cd2a1d5ece4a77
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US
Calc: threaded
Comment 6 Justin L 2021-03-18 09:25:32 UTC
repro 7.2+

Armin's 4.4 commit identified in comment 5 (https://cgit.freedesktop.org/libreoffice/core/commit/?id=6e61ecd09679a66060f932835622821d39e92f01) was the one that mostly introduced the change from RES_BACKGROUND to XATTR_FILL_*. It was a massive change that was brilliant, but also left a lot of loose ends. (Well, this is a Microsoft generated file, so not necessarily a loose end.)

Adding a background and roundtripping it works.  (Not surprising, since we are adding an XATTR_FILL properties and not RES_BACKGROUND properties now.)
<style:style style:name="fr2" style:family="graphic" style:parent-style-name="Graphics">
  <style:graphic-properties fo:background-color="#ffb66c" style:background-transparency="0%" draw:fill="solid" draw:fill-color="#ffb66c" draw:opacity="100%"

Comment 0's file only has these relevant parts:
<style:style style:family="graphic" style:name="a0" style:parent-style-name="Graphics">
<style:graphic-properties fo:background-color="#ffff00 draw:opacity="100%"

if(bSvxBrushItemPropertiesUsed && !bXFillStyleItemUsed) returns false,
because draw:opacity is considered an xFillStyle, while background-color is a BrushItem.

Removing draw:opacity="100%" "fixes" the problem.

Using LO 3.5, I round-tripped the file and the transparency saved as style:background-transparency="0%" - i.e. not draw: opacity.

So, Microsoft is mixing (or better yet - missing) attributes here. Probably best to call this NOTOURBUG? It would work in both old and new LO if Microsoft added draw:fill and draw:fill-color.