Bug 126731 - Editable pictures display as grey instead of colour in a LibreOffice Base form based on a read-only datasource
Summary: Editable pictures display as grey instead of colour in a LibreOffice Base for...
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
(earliest affected) release
Hardware: All All
: high major
Assignee: Not Assigned
Keywords: preBibisect, regression
Depends on:
Blocks: Base-Images Database-Forms
  Show dependency treegraph
Reported: 2019-08-06 16:21 UTC by britfox42
Modified: 2021-01-21 18:43 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:
Regression By:

The form (82.90 KB, image/png)
2019-08-06 16:22 UTC, britfox42
The png file (53.28 KB, image/png)
2019-08-06 16:25 UTC, britfox42
Screenshot Form with PNG image in control created on macOS LO6252 (59.17 KB, image/png)
2019-08-07 08:48 UTC, Alex Thurgood
Here is a zipped sample db. (127.79 KB, application/zip)
2019-08-07 09:32 UTC, britfox42

Note You need to log in before you can comment on or make changes to this bug.
Description britfox42 2019-08-06 16:21:00 UTC
Png pictures appears greyed inside LibreOffice Base form

Actual Results:
The png pictures are greyed.

Expected Results:
The png pictures should be in full color.

Reproducible: Always

User Profile Reset: No

Additional Info:
Comment 1 britfox42 2019-08-06 16:22:53 UTC
Created attachment 153174 [details]
The form

The form
Comment 2 britfox42 2019-08-06 16:25:04 UTC
Created attachment 153175 [details]
The png file

The png file
Comment 3 Alex Thurgood 2019-08-07 08:39:00 UTC
@britfox42 : does the PNG also have a grey area when inserted into a Writer document, or just when in your database form.

Without a sample db with which to test, it might be difficult to reproduce this bug (as it depends potentially on several different possible actions).

Please provide a sample DB and detailed steps on how to reproduce.

Setting to NEEDINFO
Comment 4 Alex Thurgood 2019-08-07 08:39:57 UTC
@britfox24 : does it make any difference to the end result if you activate/deactivate openGL support within the LO user profile ?
Comment 5 Alex Thurgood 2019-08-07 08:47:12 UTC
No repro for me with test DB (hsqldb) that I created myself. Screenshot enclosed.

Windows specific ?

Build ID: 1ec314fa52f458adc18c4f025c545a4e8b22c159
Threads CPU : 4; OS : Mac OS X 10.14.6; UI Render : par défaut; VCL: osx; 
Locale : fr-FR (fr_FR.UTF-8); Langue IHM : fr-FR
Calc: threaded
Comment 6 Alex Thurgood 2019-08-07 08:48:53 UTC
Created attachment 153192 [details]
Screenshot Form with PNG image in control created on macOS LO6252
Comment 7 Alex Thurgood 2019-08-07 08:52:13 UTC
For comparison's sake, I also inserted the provided image into a blank Writer document - no grey shading of the coloured box area.
Comment 8 britfox42 2019-08-07 09:09:46 UTC
After further tests:

- It happens with every types of picture (jpeg too)

- They appear greyed only when the "Read-only" parameter in the "General" tab of the "Image Control" form is set to "No".
Comment 9 britfox42 2019-08-07 09:32:17 UTC
Created attachment 153195 [details]
Here is a zipped sample db.
Comment 10 Alex Thurgood 2019-08-07 09:36:55 UTC
(In reply to britfox42 from comment #8)
> After further tests:
> - It happens with every types of picture (jpeg too)
> - They appear greyed only when the "Read-only" parameter in the "General"
> tab of the "Image Control" form is set to "No".

By default, that property is set to "No", at least in the test db I created using the wizard to create the form.
Comment 11 Alex Thurgood 2019-08-07 09:41:56 UTC
@britfox24 : thanks for the sample DB file. However, the problem with the JPG appears to be different to the one you experienced with the PNG ?

In the JPG file, I see a grey border around the image in the form. Is their some kind of alpha channel issue involved here ?
Comment 12 Alex Thurgood 2019-08-07 09:46:44 UTC
Adapted summary to reflect further findings.

Comment 13 Alex Thurgood 2019-08-07 09:48:00 UTC
Note that there have been issues before with rendering images containing transparent layers in certain parts of LO (cf. bug 96532)
Comment 14 britfox42 2019-08-07 09:49:35 UTC
For me, it's the exact same problem. They both appear greyed.
And the png file is in 24 bits with no alpha channel.
Comment 15 Alex Thurgood 2019-08-07 09:53:45 UTC
Sorry, should've checked the JPG first, I see that it already has a grey border around each image, so still no repro for me I'm afraid, even with your test file.
Comment 16 Alex Thurgood 2019-08-07 09:55:50 UTC
This will need to be tested by a QA member with a Windows setup.
Comment 17 Alex Thurgood 2019-08-07 10:14:50 UTC
OK, I do see the grey representation of the JPG image in your test file, I didn't immediately spot the difference (temporary colour blindness, sorry) in the eye colour.

Confirming once again, amending summary etc.

I notice that this appears to be particular to using a CSV as your datasource.
Comment 18 Alex Thurgood 2019-08-07 10:18:48 UTC
For comparison, using a test embedded hsqldb as the datasource, both the PNG and JPG supplied display in colour in the form.
Comment 19 Alex Thurgood 2019-08-07 10:26:12 UTC
I could reproduce the same buggy behaviour with a Calc sheet used as the datasource and your test JPG image
Comment 20 Alex Thurgood 2019-08-07 10:28:57 UTC
Hmm, I have a slight suspicion that this might be linked to API changes in the way graphics are loaded from a URL...
Comment 21 Alex Thurgood 2019-08-07 10:32:06 UTC
If I load your test ODB into 

LibreOffice 3.3.0 
OOO330m19 (Build:6)
tag libreoffice-

I see the colour in the JPG image in the form.

==>> regression
Comment 22 Alex Thurgood 2019-08-07 10:39:19 UTC
Hmm, seems the problem goes way back before those API changes occurred...
Comment 23 Alex Thurgood 2019-08-07 10:59:01 UTC
The image was still displaying correctly in 

Build ID: 3215f89-f603614-ab984f2-7348103-1225a5b
Comment 24 Alex Thurgood 2019-08-07 11:03:52 UTC
Incorrect display in

Version (Build ID: 58f22d5)

Bibisect range between and (probably after 3.6 branchoff)
Comment 25 Justin L 2021-01-15 13:47:34 UTC
I used bibisect-43all to arrive at the range https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=05a0b08606ac77cf7d3e294998138610b53b1b6d..bf12ddb08f60aa261f83e1688c5d589a69eea0dd

A very suspicious looking commit is:
author	Caolán McNamara on 2012-03-05 09:19:04 +0000
commit 159b5088ee303f7adf6a4c0e5e72b32c37f9f910
Resolves: fdo#31306 some icons don't get grayed when disabled
some of our menu icons are not RGBA, but our fade-out code only
handled images with an alpha channel, so we need to extend it
for bitmaps with alpha channel icons


However, EVERYTHING about this code has changed in the last 8 years. The code got split out into vcl/source/outdev/ and function names have changed etc. So the code pointers are not very helpful (at least not to me).

In my debugging build, I see the colour for a split second, and then it gets painted over with gray.
Comment 26 Justin L 2021-01-15 14:36:42 UTC
Some possible additional clues
-if you save a copy, export, or make PDF, then the gray-screening is removed
 after the save has completed.
-it is in colour when you "edit" the form (as opposed to opening it).
Comment 27 Justin L 2021-01-19 07:51:18 UTC
Perhaps this isn't really a bug after all.
If you double-click on the image, you are not prompted to browse for a replacement image. However, after the document is saved/exported, then you can replace the image. Thus the image really is disabled on form open, and thus should have some indication of that.

The form locks the image already in LO 3.5 - as far back as I can test.

OK - it has already been established that this is a read-only database. Although the form is set to allow additional records etc, none of the controls are active, and no part of the record is editable. So all data-entry parts of the form are disabled, including the image.

(In reply to britfox42 from comment #8)
> - They appear greyed only when the "Read-only" parameter in the "General"
> tab of the "Image Control" form is set to "No".

(Nice bit of investigation.) That seems counter-intuitive doesn't it? Yet that makes sense to me. If the picture is marked as read-only, then it has no need of being disabled when the database does not allow editing.

So in summary:
-this only affects read-only databases or fields - since editing is disabled
-it only affects images that are marked as editable - while editing is disabled.

It seems more and more clear to me that this is NOTABUG. And there is a logical (if somewhat unintuitive) solution for the database designer.

P.S. The bibisect range was in LO 3.6.
P.P.S. Perhaps someone could complain that exporting as PDF shouldn't remove the disable-highlighting, but who cares?