Created attachment 184165 [details] Active selections from the tabbed menu bar have light blue backgrond which makes the white icon alsmost invisible Dark Mode on Windows 11 shows lightblue border for active items in the tabbed menu bar which makes icons and it's text almost invisible as those are mostly white itself. The border collor of the active its (screenhot attached) maybe should have a dark fill with the collor of the tabbed menu bar itself (or slightly lighter). That what an active item has the light blueborder with a dark fill which makes the white icon better visible.
Version: 7.5.0.0.beta1 (X86_64) / LibreOffice Community Build ID: 3aca23eec42e9d6fbe57071d7633ae1fc4bc5fcc CPU threads: 16; OS: Windows 10.0 Build 22621; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: nl-NL Calc: CL threaded
Can't reproduce with Windows 10 and default dark mode colours: Version: 7.5.0.1 (X86_64) / LibreOffice Community Build ID: 77cd3d7ad4445740a0c6cf977992dafd8ebad8df CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: en-GB (en_GB); UI: en-GB Calc: threaded
Same issue in 7.5.0.2. Version: 7.5.0.2 (X86_64) / LibreOffice Community Build ID: c0dd1bc3f1a385d110b88e26ece634da94921f58 CPU threads: 16; OS: Windows 10.0 Build 22621; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: nl-NL Calc: CL threaded
Marking as new as I can see the same in Rizal's post: https://libreofficemaster.blogspot.com/2022/03/libreoffice-dark-mode-on-windows.html
It seems this is a bug in Windows 11. Notepad++ also faced this issue and they come with a workaround (the text and image underneath is automatically inverted upon selection): issue: https://github.com/notepad-plus-plus/notepad-plus-plus/issues/10510 workaround: https://github.com/notepad-plus-plus/notepad-plus-plus/pull/10685 I can confirm this bug is still present in the latest beta insider of Windows 11.
Created attachment 185222 [details] Notepad++ workaroud
*** Bug 153511 has been marked as a duplicate of this bug. ***
(In reply to dulven123 from comment #5) > It seems this is a bug in Windows 11. Notepad++ also faced this issue and > they come with a workaround (the text and image underneath is automatically > inverted upon selection): > issue: https://github.com/notepad-plus-plus/notepad-plus-plus/issues/10510 > workaround: https://github.com/notepad-plus-plus/notepad-plus-plus/pull/10685 > > I can confirm this bug is still present in the latest beta insider of > Windows 11. Caolán, what do you think? Not our bug? Can we do a similar workaround?
Created attachment 185297 [details] Windows 10 for reference Windows 10 looks ok AFAICS. Apparently my Windows box is not eligible for upgrade to Windows 11 so someone else will have to investigate if this is still a problem and what the solution might be.
*** Bug 155392 has been marked as a duplicate of this bug. ***
Duplicate bug 155392 tells us it is still current in 7.5.3.2.
Can confirm that this is still an issue in 7.6.0.0.alpha1. Version: 7.6.0.0.alpha1 (X86_64) / LibreOffice Community Build ID: 9366f83c88fc93d40ea0c0035508f24ad5dcb144 CPU threads: 24; OS: Windows 10.0 Build 22621; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded ^ Again, it says that I'm on Win10, but I'm on Win11 22H2.
(In reply to haxellio from comment #12) > Again, it says that I'm on Win10, but I'm on Win11 22H2. We know you are on Windows 11. Any build 22621 is Win11, not Win10--blame Microsoft's SDK not keeping up with MS Marketing. https://en.wikipedia.org/wiki/Windows_10_version_history https://en.wikipedia.org/wiki/Windows_11_version_history
*** Bug 155499 has been marked as a duplicate of this bug. ***
The Notebook Bar UIs were tweaked for bug 152454 for Win11 to not use Buttons for the tabs [1] and set better colors [2]. To support Win11 dark theme, something similar may be needed to render selected toggles for button widgets bcz MSSTYLES handling at Win11 muddles fg and bg assignment. =-ref-= [1] https://gerrit.libreoffice.org/c/core/+/144046 [2] https://gerrit.libreoffice.org/c/core/+/144045
I confirm, the error is still in version 7.5.3 and 7.6.0.0.alpha1 of libreoffice in Windows 11, I don't know if the same error is present in other operating systems.
Some more details on this bug from me: https://github.com/derceg/explorerplusplus/issues/115#issuecomment-1598660527 Response from Explorer++ developer: https://github.com/derceg/explorerplusplus/issues/115#issuecomment-1600267784 Basically, this bug is due to a change within aero.msstyles theme file since the very first Windows 11 release. They only changed BUTTON resource for some reason to this terrible light/bright blue color. They never changed SPLITBUTTON resource though which is odd. The bug does not affect users who use a custom msstyles theme though, which of course is unsupported by Microsoft. It only affects default Aero theme. This seems to affect programs that utilize win32-darkmode functionality, such as Notepad++, Explorer++, LibreOffice and possibly more that I am not aware of. I believe one of the only solutions at the moment would be custom drawing of each button.
(In reply to WildByDesign from comment #17) > ... > I believe one of the only solutions at the moment would be custom drawing of > each button. But it also looks like a Win11 work around is possible for LibreOffice (awaiting some MS movement to fix their issue with the Win11 image color in aero.theme) as Don HO did for Notepad++ issue 10510 and and pull 10685 [1][2] with: https://github.com/notepad-plus-plus/notepad-plus-plus/commit/5d086f93a80d275fcc5e4047ae49c614680a7e5b testing for Windows 11 build, to reverse the fg color of the button text when hot. Can't fix the image color/transparency issue--but can allow the icon to show with some contrast. =-ref-= [1] Notepad++ https://github.com/notepad-plus-plus/notepad-plus-plus/issues/10510 [2] Notepad++ https://github.com/notepad-plus-plus/notepad-plus-plus/pull/10685/commits
Within the past week, there has been 4 users on the LibreOffice subreddit who brought this exact issue up: - https://www.reddit.com/r/libreoffice/comments/14oze66/just_got_libreoffice_and_ive_some_questions/jqjdjat/ - https://www.reddit.com/r/libreoffice/comments/14osggh/dark_mode_light_mode_either_way_any_toggle/jqlaot0/ - https://www.reddit.com/r/libreoffice/comments/14ql72o/how_do_i_fix_this_bad_contrasting_when_in_dark/jqotku9/ (The first topic was even a very first-time user of LibreOffice—so probably not a great first impression!) If there was 4 complaints within a week, I'm suspecting there are many other silent Windows 11 users out there being hit by this issue as well. No pressure though. :)
Also brought up on ask.LO: https://ask.libreoffice.org/t/cannot-read-highlighted-option-text-in-light-mode/88474
Stuart, any reason why you removed the "accessibility" keyword? To me, this is clearly an issue that affects accessibility – see for example first-hand user account here: https://www.reddit.com/r/libreoffice/comments/14oze66 I've added it back but please let me know if it wasn't an error. Michael, adding you to CC in case you are interested.
(In reply to Stéphane Guillou (stragu) from comment #21) > Stuart, any reason why you removed the "accessibility" keyword? To me, this > is clearly an issue that affects accessibility – see for example first-hand > user account here: https://www.reddit.com/r/libreoffice/comments/14oze66 > > I've added it back but please let me know if it wasn't an error. > > Michael, adding you to CC in case you are interested. Don't see it as an accessibility issue. Believe we handle (consume the os/DE color scheme) for the Win11 Ease-of-Access "Contrast themes" when set active on os/DE for all four of the Win11 HC themes: "Aquatic" "Desert" "Dusk" "Night Sky" The buggy button handling does not affect those Win11 HC themes (msstyles) and our AT tools perform as intended. Instead, this is a simple issue in a MS default color theme for buttons--Microsoft picked a stinker bg fill color for Win11 activated button. We can possibly perform an inversion of button fg / bg, but the current bg color comes from the os/DE theme. The a11y themes which now also follow respective os/DE theme aren't affected--they have a theme specific button handling.
(In reply to WildByDesign from comment #17) > Basically, this bug is due to a change within aero.msstyles theme file since > the very first Windows 11 release. They only changed BUTTON resource for > some reason to this terrible light/bright blue color. They never changed > SPLITBUTTON resource though which is odd. I don't have Windows 11 to test myself, but I'm wondering whether this been reported to Microsoft? Maybe emphasizing the problem on their end might help to increase importance there as well, and at least ideally this should be fixed where the actual root cause is...
(In reply to Michael Weghorn from comment #23) > I don't have Windows 11 to test myself, but I'm wondering whether this been > reported to Microsoft? Maybe emphasizing the problem on their end might help > to increase importance there as well, and at least ideally this should be > fixed where the actual root cause is... That's a good question but unfortunately I don't know the answer. I honestly don't even know how to find out if it's been reported before or how exactly to report it properly. This bug has been around since the very first public build (22000) of Windows 11. I have done some more research into this aero.msstyles bug since my last comment in this LibreOffice bug thread. Apparently, the theme file does contain the correct dark mode BUTTON resource but for some reason it is not being utilized and instead pulls the light mode BUTTON resource. You can see my more recent comment (and msstyles resource comparison image) on the Explorer++ Github page: https://github.com/derceg/explorerplusplus/issues/115#issuecomment-1617115230 In that same comment, I ask the developer how someone should properly report this to Microsoft. He would have a better understanding of what is actually happening with the code and under the surface with the operating system. I haven't got a response back yet.
(In reply to WildByDesign from comment #24) > In that same comment, I ask the developer how someone should properly report > this to Microsoft. He would have a better understanding of what is actually > happening with the code and under the surface with the operating system. I > haven't got a response back yet. Great, thanks a lot! I see that the issue has been reported to Microsoft now, as this comment mentions: https://github.com/derceg/explorerplusplus/issues/115#issuecomment-1657405123 (I can't the link to the Microsoft Feedback Hub provided there to check the actual status without having to install an extra app, though...)
The developer of Explorer++, David Erceg, who has a good understanding of the win32-darkmode implementations has followed up with a nicely detailed response. Link: https://github.com/derceg/explorerplusplus/issues/115#issuecomment-1666308914 Some of my takeaways from the response: - The issue is not likely specific to the aero.msstyles theme resource file itself, but more likely issues within the dark mode API (within Windows) that pulls data from the theme resource file. - "Even with the use of the undocumented APIs and classes from aero.msstyles, partially or fully drawing controls is still necessary to achieve a cohesive result." - The fact that win32-darkmode consists of undocumented APIs, these issues would be unsupported and extremely unlikely that Microsoft would ever fix these issues. Since Microsoft requires installing an app just to vote for the issue to be fixed, that makes it much more difficult to bring attention to the issue. There is often issues in Windows which get 10s of thousands of votes before it puts enough pressure on Microsoft to implement whatever fix or feature update. I don't hold much hope on this issue, unfortunately. Also, from my own personal opinion, that workaround that Notepad++ which simply inverts the color, is still quite terrible. That workaround would still be bad for any users with vision problems. Also it's quite jarring regardless from a visual perspective. I created an msstyles alternative (https://github.com/WildByDesign/Aero.msstyles-win32-darkmode) which is essentially default aero.msstyles file with the one and only change to it being swapping the terrible bright blue highlight to a proper dark mode highlight for toolbar icons. Yet still, getting users to install a separate aero.msstyles theme is not a great workaround either. I created this mostly with vision impaired users in mind. I still believe that custom drawing the toolbar icons is the only proper way to fix this bug and it seems to be what David Erceg (Explorer++ dev) is also suggesting.
*** Bug 157017 has been marked as a duplicate of this bug. ***
Removing "notebook bar and sidebar UI" from the summary as https://libreofficemaster.blogspot.com/2022/03/libreoffice-dark-mode-on-windows.html shows it in the standard toolbars as well.
*** Bug 157257 has been marked as a duplicate of this bug. ***
(In reply to Stéphane Guillou (stragu) from comment #29) > *** Bug 157257 has been marked as a duplicate of this bug. *** Thanks (ou "merci", au vu du prénom) Stéphane and sorry for the duplicate. I searched for a long time but didn't find this bug 152534. Happy to not be the only one having it and seeing the problem!
I can confirm that (In reply to WildByDesign from comment #26) > The developer of Explorer++, David Erceg, who has a good understanding of > the win32-darkmode implementations has followed up with a nicely detailed > response. > > Link: > https://github.com/derceg/explorerplusplus/issues/115#issuecomment-1666308914 > > Some of my takeaways from the response: > > - The issue is not likely specific to the aero.msstyles theme resource file > itself, but more likely issues within the dark mode API (within Windows) > that pulls data from the theme resource file. > > - "Even with the use of the undocumented APIs and classes from > aero.msstyles, partially or fully drawing controls is still necessary to > achieve a cohesive result." > > - The fact that win32-darkmode consists of undocumented APIs, these issues > would be unsupported and extremely unlikely that Microsoft would ever fix > these issues. > > Since Microsoft requires installing an app just to vote for the issue to be > fixed, that makes it much more difficult to bring attention to the issue. > There is often issues in Windows which get 10s of thousands of votes before > it puts enough pressure on Microsoft to implement whatever fix or feature > update. I don't hold much hope on this issue, unfortunately. > > Also, from my own personal opinion, that workaround that Notepad++ which > simply inverts the color, is still quite terrible. That workaround would > still be bad for any users with vision problems. Also it's quite jarring > regardless from a visual perspective. > > I created an msstyles alternative > (https://github.com/WildByDesign/Aero.msstyles-win32-darkmode) which is > essentially default aero.msstyles file with the one and only change to it > being swapping the terrible bright blue highlight to a proper dark mode > highlight for toolbar icons. Yet still, getting users to install a separate > aero.msstyles theme is not a great workaround either. I created this mostly > with vision impaired users in mind. > > I still believe that custom drawing the toolbar icons is the only proper way > to fix this bug and it seems to be what David Erceg (Explorer++ dev) is also > suggesting. Thanks WildByDesign, your solution on GitHub works great! I'm not sure what the best place would be, but it'd be great if this was also linked in the official support somewhere or anywhere more obvious -- it the only way I've found to make Windows 11 dark mode usable and it took some *finding*.
And there was 1 more completely-new-to-LibreOffice Windows 11 user who reported this on the subreddit: - https://www.reddit.com/r/libreoffice/comments/182siys/new_to_lo_two_issues_so_far_windows/
*** Bug 158864 has been marked as a duplicate of this bug. ***
Just to reiterate observation of comment 22, the a11y Win11 "Contrast themes" are not affected by this MS issue with unsupported split button in win32 aero.msstyles Using the provided Win11 "Aquatic", "Desert", "Dusk", or "Night sky" contrast themes receive button color assignments that keep sufficient contrast. =-testing-= Version: 7.6.4.1 (X86_64) / LibreOffice Community Build ID: e19e193f88cd6c0525a17fb7a176ed8e6a3e2aa1 CPU threads: 8; OS: Windows 10.0 Build 22621; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded
*** Bug 159504 has been marked as a duplicate of this bug. ***
*** Bug 161028 has been marked as a duplicate of this bug. ***
I also had this occur on Windows 10; LibreOffice 24.2.3. With a custom Windows theme, dark mode enabled. It resolved itself after: 1. I enabled "Force skia software rendering" 2. Changed the icon set 3. Restarted LibreOffice 4. Selected Sakapura (SVG + dark) 5. Disabled "Force skia software rendering" 6. Restarted LibreOffice. I have now upgraded to Windows 11 so unfortunately am not in a position to test this further. It did not reoccur on Windows 11 as it was an upgrade, I did not replace my LibreOffice profile, and my custom Windows theme transferred over to Windows 11 unchanged (as far as I can tell).
Further to my last comment https://bugs.documentfoundation.org/show_bug.cgi?id=152534#c37 I recently upgraded to 24.8 and had to create a new LibreOffice user profile and the steps to correct this issue in my previous comment no longer work. I'm back to having unreadable activated icons in dark mode regardless of the settings. I have tried using my old profile with 24.8 and the icons now display like everyone else.