Bug 168600 - Automatic color on this slide produces white-on-white text
Summary: Automatic color on this slide produces white-on-white text
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
4.2.0.4 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Automatic-Color
  Show dependency treegraph
 
Reported: 2025-09-29 08:06 UTC by Eyal Rozenberg
Modified: 2025-09-29 19:03 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
Presentation exhibiting the bug (72.58 KB, application/vnd.oasis.opendocument.presentation)
2025-09-29 08:09 UTC, Eyal Rozenberg
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Eyal Rozenberg 2025-09-29 08:06:34 UTC
Consider the attached presentation (based on the template for LibOCon 2024). If I create a textbox in the (single) slide, and type some text - it comes out white, when the slide background is white.
Comment 1 Eyal Rozenberg 2025-09-29 08:09:35 UTC
Created attachment 203013 [details]
Presentation exhibiting the bug
Comment 2 Eyal Rozenberg 2025-09-29 08:10:04 UTC
Observed with:

Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 0d986755e4153230670c820dc52cc40cd72dfa87
CPU threads: 4; OS: Linux 6.12; UI render: default; VCL: gtk3
Locale: en-IL (en_IL); UI: en-US
Calc: CL threaded

but also with some 24.8 release last year.
Comment 3 raal 2025-09-29 18:04:20 UTC
Confirm with Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 8ea8e254a3151f5390f3a10ff156fcaf8e7c5d5c
CPU threads: 4; OS: Linux 6.8; UI render: default; VCL: gtk3
Locale: cs-CZ (cs_CZ.UTF-8); UI: en-US
Calc: threaded


Version: 6.1.0.0.alpha1+
Build ID: 3a801799536e6870f2fb111b1cc00b9575a35a39

It's correct in Version 4.1.0.0.alpha0+ (Build ID: efca6f15609322f62a35619619a6d5fe5c9bd5a)
Comment 4 raal 2025-09-29 18:12:45 UTC
This seems to have begun at the below commit in bibisect repository/OS bibisect-41max.
Adding Cc: to Armin Le Grand ; Could you possibly take a look at this one?
Thanks
 144707a038dc79b014f1d8f00af1d2ed076ba5ea is the first bad commit
commit 144707a038dc79b014f1d8f00af1d2ed076ba5ea
Author: Matthew Francis <mjay.francis@gmail.com>
Date:   Fri Sep 18 10:45:33 2015 +0800

    source-hash-c97aec0d2276901c20634abe53867f739f420f50
    
    commit c97aec0d2276901c20634abe53867f739f420f50
    Author:     Armin Le Grand <alg@apache.org>
    AuthorDate: Thu May 10 09:29:55 2012 +0000
    Commit:     Caolán McNamara <caolanm@redhat.com>
    CommitDate: Fri Mar 15 15:24:52 2013 +0000
    
        Related: #i119125# change XFillBitmapItem to work with GraphicObject
    
        Completely changed XFillBitmapItem to work with GraphicObject, removed XOBitmap
        class, adapted all usages (also the pretty old 8x8 pixel editor).
    
        All Bitmap fill styles will now accept transparent bitmaps as fillings in all
        variations (tiled, etc.). LoadSave is no problem, ODF defines graphic as
        content for fill.  Backward means that OOs before this change will use a white
        background of fill with transparent, same as the fallback all the time when
        using a transparent fill.
    
        This is also a preparation to e.g. offer SVG or Metafiles as fill style.
Comment 5 Eyal Rozenberg 2025-09-29 19:03:08 UTC
raal, Armin, this is the second issue I've filed today that is a regression of a rather-common usage pattern. And it might be only the second since I haven't even got started on filing my Impress bugs from LibOCon 2025 :-(

What I want to say is: I have a sensation we are lacking some tests which cover enough typical presentation-making actions; and that we are not dogfooding well enough. What do you guys think? Am I just extrapolating too much?