Bug Hunting Session
Bug 121028 - Table background bitmap replaced Painted White when changing the border color
Summary: Table background bitmap replaced Painted White when changing the border color
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.2.0.0.alpha1+
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Writer-Tables
  Show dependency treegraph
 
Reported: 2018-10-29 15:32 UTC by Telesto
Modified: 2019-05-06 21:34 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
screencast (1.46 MB, video/mp4)
2018-12-02 15:58 UTC, Xisco Faulí
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2018-10-29 15:32:29 UTC
Description:
Table background bitmap replaced when changing the border color

Steps to Reproduce:
1. Insert a table
2. Select the table
3. Table - Properties
4. Background Tab -> Bitmap -> Choose: Clouds
5. Press OK
6. Table - Properties
7. Borders tab
8. Change border line color
9. Press OK

Actual Results:
 Painted White

Expected Results:
Clouds


Reproducible: Always


User Profile Reset: No



Additional Info:
Version: 6.2.0.0.alpha1+
Build ID: cb7500ddb8de6c41fca84a0009ffe22240bb1845
CPU threads: 4; OS: Windows 6.3; UI render: default; VCL: win; 
TinderBox: Win-x86@42, Branch:master, Time: 2018-10-29_03:24:02
Locale: nl-NL (nl_NL); Calc: CL
Comment 1 Dieter Praas 2018-10-29 17:03:47 UTC
Must be a very recent bug, because I can't reproduce with

Version: 6.2.0.0.alpha1+ (x64)
Build ID: 8274c4c62df5b937b3f0bec9e1eeca85f3b219d4
CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2018-10-22_01:47:50
Locale: en-US (de_DE); Calc: CL
Comment 2 Chiang Han 2018-11-29 08:19:25 UTC
Bug confirmed.

Follow all the steps,it can reproduce.
Not just the cloud,you use the other ones will cause the same result.

Additional Info:
Version: 6.3.0.0.alpha0+ (x64)
Build ID: 0f25a3c36f27fd51453b9a9115f236b83c143684
CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2018-11-27_20:06:55
Locale: zh-TW (zh_TW); UI-Language: en-US
Comment 3 Dieter Praas 2018-11-29 08:32:04 UTC
(In reply to Chiang Han from comment #2)
> Bug confirmed.
> 

Chiang, if you can confirm a bug, you are also allowed to change teh status to NEW

=> set to NEW because of comment 2

I also add bibisectRequest, because I couldn't reproduce it in older version of the master (see comment 1)
Comment 4 Xisco Faulí 2018-11-29 10:56:02 UTC
Reproduced in

Version: 6.2.0.0.beta1+
Build ID: ce7bb69f8205bcbe36cba4c53bd110e07ef3e05d
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 5 Xisco Faulí 2018-11-29 11:09:33 UTC
Regression introduced by:

https://cgit.freedesktop.org/libreoffice/core/commit/?id=4f6e104499625d69d2b37271d0fee52848c0a6d4

author	Jim Raykowski <raykowj@gmail.com>	2018-08-09 20:07:35 -0800
committer	Tamás Zolnai <tamas.zolnai@collabora.com>	2018-10-09 11:30:34 +0200
commit	4f6e104499625d69d2b37271d0fee52848c0a6d4 (patch)
tree	2d1bb1bade8399f5e285416eca47f81b7c96ad8c
parent	383a4f883d4a2932167695c761611b998f773f0e (diff)
tdf#111718 Fix interaction between bitmap and pattern settings

Bisected with: bibisect-linux64-6.2

Adding Cc: to Jim Raykowski
Comment 6 Jim Raykowski 2018-11-29 12:33:11 UTC
Hi All,
 
I don't repro with version 6.3.0.0.alpha0+
Linux or Windows.
Comment 7 Xisco Faulí 2018-11-29 12:35:15 UTC
(In reply to Jim Raykowski from comment #6)
> Hi All,
>  
> I don't repro with version 6.3.0.0.alpha0+
> Linux or Windows.

Still reproducible in

Version: 6.3.0.0.alpha0+
Build ID: 00df4a5ae395607eab1f83aacfc1fb05eb93ecc9
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 8 Jim Raykowski 2018-11-29 13:10:22 UTC
Insert Table dialog uses Default Style by default which is an autoformat style and will produce unexpected behaviour when direct formatting is done. When did  Default Style became default in the Insert Table dialog? 

I used the Insert Table toolbar button which uses no style so I didn't repro at first. Same can be done using Insert Table dialog by selecting None in Styles list box.
Comment 9 Xisco Faulí 2018-12-02 15:56:33 UTC
Hi Jim,
I think the problem is the second time the properties dialog is open, the first bitmap is selected, thus it's applied after closing the dialog... I'm going to attach a screncast
Comment 10 Xisco Faulí 2018-12-02 15:58:10 UTC
Created attachment 147230 [details]
screencast
Comment 11 Jim Raykowski 2018-12-02 17:55:19 UTC
Unfortunately, AFAIK, this has always been the behavior when using bitmap backgrounds with tables, sections, and  table of contents. It has to do with how these backgrounds are stored without any identification. 

Here is a clip from an .fodt (flat) file showing that no identification is stored for the bitmap, just binary data.

  <style:style style:name="Table1.C5" style:family="table-cell">
    <style:table-cell-properties fo:background-color="transparent" fo:padding="0.0382in" fo:border="none">
      <style:background-image>
         <office:binary-data> binary data is here
         </office:binary-data>
      </style:background-image>
    </style:table-cell-properties>
  </style:style>
Comment 12 Jim Raykowski 2018-12-02 19:01:11 UTC
(In reply to Jim Raykowski from comment #8)
> Insert Table dialog uses Default Style by default which is an autoformat
> style and will produce unexpected behaviour when direct formatting is done.
> When did  Default Style became default in the Insert Table dialog? 
> 
> I used the Insert Table toolbar button which uses no style so I didn't repro
> at first. Same can be done using Insert Table dialog by selecting None in
> Styles list box.

sorry this was for another bug as was comment 6
Comment 13 Regina Henschel 2018-12-02 19:27:39 UTC
I think, it is not a problem with storing, but only with the new Area dialog. The dialog lacks a list of "used in document images", or at least should not preselect an image but refer to the currently assigned one. A similar problem exists in bug 107087 and its duplicate 103262.

Binary data is only used in flat format, otherwise the pictures are stored in "Pictures" folder.

The <style:background-image> is child-child of a style, which has a name, and therefore can always be identified by that name. It is up to the implementation to use this information.
Comment 14 Jim Raykowski 2018-12-03 02:51:12 UTC
Here is a code pointer to why the bitmap is not re-selected:

https://opengrok.libreoffice.org/xref/core/svx/source/unodraw/unobrushitemhelper.cxx#66

There seems not to be a method to retrieve the name of the bitmap from the graphic object so it is always set to empty string.
Comment 15 Jim Raykowski 2019-01-24 08:28:30 UTC
I think this patch fixes this
https://gerrit.libreoffice.org/#/c/66838/
Comment 16 Jim Raykowski 2019-05-04 06:34:04 UTC
I do not repro the behavior shown in Xisco's screencast using:

Version: 6.3.0.0.alpha0+
Build ID: 8dabb2ae2d34f94a50ef5f94bf4bf01b2aca2071
CPU threads: 4; OS: Linux 4.18; UI render: default; VCL: gtk3; 
Locale: en-US (en_US.UTF-8); UI-Language: en-US
Calc: threaded

Setting this to Resolved Fixed
Comment 17 Xisco Faulí 2019-05-06 10:32:50 UTC
Verified in

Version: 6.3.0.0.alpha0+
Build ID: ddea172792d13516ff7e0dd43f1f78b74ade8914
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

@jim raykowski, thanks for fixing this issue!!
Comment 18 Xisco Faulí 2019-05-06 10:51:25 UTC
actually this issue got fixed by https://cgit.freedesktop.org/libreoffice/core/commit/?id=222b5b5b9b0d0419e30961261c63ff8585550b81
Comment 19 Xisco Faulí 2019-05-06 11:08:08 UTC
(In reply to Xisco Faulí from comment #18)
> actually this issue got fixed by
> https://cgit.freedesktop.org/libreoffice/core/commit/
> ?id=222b5b5b9b0d0419e30961261c63ff8585550b81

actually it's not... the patch is in LibreOffice 6.2.3 and I can still reproduce this problem on that version... Backporting the commit in comment 15 then -> https://gerrit.libreoffice.org/#/c/71855/
Comment 20 Xisco Faulí 2019-05-06 21:34:51 UTC
Fix in

Version: 6.2.5.0.0+
Build ID: 6c3ceaf3e4d59c658d0f9e4e1b22204be25f74e2
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

after https://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-6-2&id=6c3ceaf3e4d59c658d0f9e4e1b22204be25f74e2