Bug 115400 - Toolbar background is white despite using Windows theme "High contrast black"
Summary: Toolbar background is white despite using Windows theme "High contrast black"
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
6.0.0.3 release
Hardware: All Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: accessibility, bibisected, bisected, regression
: 119237 120090 (view as bug list)
Depends on:
Blocks: UI-Theming
  Show dependency treegraph
 
Reported: 2018-02-02 12:18 UTC by Jernej Simončič
Modified: 2021-11-22 00:41 UTC (History)
5 users (show)

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


Attachments
Screenshot of the problem (54.52 KB, image/png)
2018-02-02 12:18 UTC, Jernej Simončič
Details
Toolbar High Contrast problem in 6.1.0.3 (80.60 KB, image/png)
2018-09-07 16:43 UTC, Jernej Simončič
Details
6.3.1.2 screenshot showing the bug (134.99 KB, image/png)
2019-10-25 07:07 UTC, Jernej Simončič
Details
theme-dark-01.png (55.24 KB, image/png)
2019-11-17 13:56 UTC, Sebastiaan Veld
Details
theme-dark-02.png (56.79 KB, image/png)
2019-11-17 13:56 UTC, Sebastiaan Veld
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jernej Simončič 2018-02-02 12:18:13 UTC
Description:
I just upgraded to LibreOffice 6.0.0.3, and now toolbar backgrounds are white instead of following the Windows hight contrast theme (and I haven't been able to find any way to change this in the settings).

Steps to Reproduce:
1. set Windows to dark high-contrast theme
2. run any of the LibreOffice programs


Actual Results:  
Toolbar background is white

Expected Results:
Toolbar background uses theme colour


Reproducible: Always


User Profile Reset: No



Additional Info:


User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.121 Safari/537.36 Vivaldi/1.95.1077.41
Comment 1 Jernej Simončič 2018-02-02 12:18:36 UTC
Created attachment 139525 [details]
Screenshot of the problem
Comment 2 Buovjaga 2018-02-24 17:15:15 UTC
Reproduced. It kind of feels like the return of bug 43131.
I mean even High contrast white looks bad (see the bold, italics, underline, align icons).

Version: 6.0.1.1 (x64)
Build ID: 60bfb1526849283ce2491346ed2aa51c465abfe6
CPU threads: 4; OS: Windows 10.0; UI render: default; 
Locale: fi-FI (fi_FI); Calc: group
Comment 3 Buovjaga 2018-09-07 13:19:04 UTC
*** Bug 119237 has been marked as a duplicate of this bug. ***
Comment 4 Jernej Simončič 2018-09-07 16:43:27 UTC
Created attachment 144742 [details]
Toolbar High Contrast problem in 6.1.0.3

Problem persists in 6.1.0.3.
Comment 5 Buovjaga 2018-10-23 13:12:37 UTC
*** Bug 120090 has been marked as a duplicate of this bug. ***
Comment 6 QA Administrators 2019-10-25 02:40:31 UTC Comment hidden (obsolete)
Comment 7 Jernej Simončič 2019-10-25 07:07:14 UTC
Created attachment 155293 [details]
6.3.1.2 screenshot showing the bug

Bug is still present in 6.3.1.2.

Help → About:

Različica: 6.3.1.2 (x64)
ID gradnje: b79626edf0065ac373bd1df5c28bd630b4424273
Niti CPE: 8; Op. sistem: Windows 10.0; Upodobitev vmesnika: privzeta; VCL: win; 
Področna nastavitev: sl-SI (sl_SI); Jezik vmesnika: sl-SI
Calc: threaded
Comment 8 QA Administrators 2019-10-26 02:09:19 UTC Comment hidden (obsolete)
Comment 9 Sebastiaan Veld 2019-11-17 13:54:19 UTC
In 6.3.3.2 and 6.4.0.0.alpha1 this issue is still present;

Versie: 6.3.3.2 (x64)
Build ID: a64200df03143b798afd1ec74a12ab50359878ed
CPU-threads: 4; Besturingssysteem: Windows 10.0; UI-render: GL; VCL: win; 
Locale: nl-NL (nl_NL); UI-taal: nl-NL
Calc: threaded


Versie: 6.4.0.0.alpha1 (x64)
Build ID: cc57df8f942f239d29cb575ea5a7cb01405db787
CPU-threads: 4; Besturingssysteem: Windows 10.0 Build 17763; UI-render: GL; VCL: win; 
Locale : nl-NL (nl_NL); UI-taal: nl-NL
Calc: threaded

Attached:
* theme-dark-01.png
* theme-dark-02.png

Steps to reproduce:
* Star LO Writer with a clean profile, in Extra Settings set you Personal Theme to Dark as shown in theme-dark-01.png
* Shutdown LO and restart Writer, now the Theme appears as in theme-dark-02.png
Comment 10 Sebastiaan Veld 2019-11-17 13:56:15 UTC
Created attachment 155893 [details]
theme-dark-01.png
Comment 11 Sebastiaan Veld 2019-11-17 13:56:42 UTC
Created attachment 155894 [details]
theme-dark-02.png
Comment 12 QA Administrators 2021-11-17 05:11:38 UTC Comment hidden (obsolete)
Comment 13 Jernej Simončič 2021-11-17 07:52:42 UTC
Bug is still present in LibreOffice 7.2.2.2, and as my original comment states, this regression started with LibreOffice 6.0 – v5 did not have this problem.
Comment 14 Deep17 2021-11-21 05:44:26 UTC
Regression introduced by :

https://git.libreoffice.org/core/commit/7f0bf6220bd69cf119878ebd1352b55a042b88ed

commit 7f0bf6220bd69cf119878ebd1352b55a042b88ed	[log]
author	Stephan Bergmann <sbergman@redhat.com>	Wed Oct 04 10:16:31 2017 +0200
committer	Stephan Bergmann <sbergman@redhat.com>	Wed Oct 04 13:45:39 2017 +0200
tree 30590d14fbe352ddedb20ce3c916657939a64ebd
parent aed1870375cd2b718fcc5fe19cdc27b711747d9c [diff]

Bisected with : win32-6.0

Adding CC : to Stephan Bergmann
Comment 15 Buovjaga 2021-11-21 11:47:23 UTC
(In reply to Deep17 from comment #14)
> Regression introduced by :
> 
> https://git.libreoffice.org/core/commit/
> 7f0bf6220bd69cf119878ebd1352b55a042b88ed

It doesn't seem like the correct result. Did you check it by saying git checkout for the binary hash of the bad commit, testing, then moving to the preceding commit by saying git checkout HEAD^ and testing again (bug should not appear)?

You can find out the binary hash of the bad commit with this when in the win32-6.0 repo:

git log --all --grep='7f0bf6220bd69cf119878ebd1352b55a042b88ed'
Comment 16 Deep17 2021-11-22 00:41:02 UTC
(In reply to Buovjaga from comment #15)
> (In reply to Deep17 from comment #14)
> > Regression introduced by :
> > 
> > https://git.libreoffice.org/core/commit/
> > 7f0bf6220bd69cf119878ebd1352b55a042b88ed
> 
> It doesn't seem like the correct result. Did you check it by saying git
> checkout for the binary hash of the bad commit, testing, then moving to the
> preceding commit by saying git checkout HEAD^ and testing again (bug should
> not appear)?
> 
> You can find out the binary hash of the bad commit with this when in the
> win32-6.0 repo:
> 
> git log --all --grep='7f0bf6220bd69cf119878ebd1352b55a042b88ed'

I followed the steps you mentioned. I can see bug in the git checkout for the binary hash of the bad commit and I couldn't see bug on git checkout HEAD^.