Description: In todays nightly build font and grid color in calc seem wrong in dark mode. Font color defaulting to "Automatic". Steps to Reproduce: Open calc and type into cell Actual Results: Automatic font color is black on black document background making the entire spreadsheet appear black. Same goes for grid lines. Expected Results: In dark mode with black document background, font should be white and grid lines light grey (or white?). Reproducible: Always User Profile Reset: No Additional Info: Version: 25.8.0.0.alpha0+ (AARCH64) / LibreOffice Community Build ID: f6944d251f6eb4ad2bcf6cee6027a83e44d72364 CPU threads: 12; OS: macOS 15.3.1; UI render: Skia/Raster; VCL: osx Locale: de-DE (en_US.UTF-8); UI: en-US Calc: threaded
Created attachment 199440 [details] 2025-02-25 main build, black font and grid on black document background
Created attachment 199441 [details] 2025-02-25 main build, black font and grid on black document background settings
Although I cannot reproduce this in the 25 February 2025 nightly build, I did see this occur once in my following comment with LibreOffice 25.2.0.3: https://bugs.documentfoundation.org/show_bug.cgi?id=165382#c6 For me, deleting my LibreOfficeDev preferences folder eliminated the problem. But I didn't save the deleted folder so I cannot reproduce this bug. Is it possible for you to upload a zip file of your ~/Library/Application Support/LibreOfficeDev folder? I can then swap in your preferences folder and run the nightly build on my machine. My hope is that it is just a Calc preference that causes this.
You got mail.
Not limited to Calc, this affects all components.
I can now reproduce this with @steve's preferences folder. I'll start debugging this: Version: 25.8.0.0.alpha0+ (AARCH64) / LibreOffice Community Build ID: f6944d251f6eb4ad2bcf6cee6027a83e44d72364 CPU threads: 8; OS: macOS 15.3.1; UI render: Skia/Raster; VCL: osx Locale: de-DE (en_CA.UTF-8); UI: en-US Calc: threaded
I found a way to stop this bug: 1. Select the LibreOffice > Settings menu item and the Options dialog will appear 2. Select LibreOffice > Appearance in the left sidebar and then press then the "Reset All" button 3. Press the "OK" button to close the Options dialog I see that doing the above steps adds a lot of the following type of entries in the registrymodifications.xcu preference file: <item oor:path="/org.openoffice.Office.UI/ColorScheme/ColorSchemes/org.openoffice.Office.UI:ColorScheme['COLOR_SCHEME_LIBREOFFICE_AUTOMATIC']/ I don't know anything about the code that manages preferences so I'll reach out to the developer's mailing list to see if anyone can make sense of what is happening.
@steve: can you e-mail your preferences link to @Sahil? He has some ideas on what might be causing this bug: https://bugs.documentfoundation.org/show_bug.cgi?id=165382#c11
Mail to Sahil is out. Have not taken the workaround steps in order to test potential upcoming patches.
Created attachment 199446 [details] ~/Library/Application\ Support/LibreOffice folder that causes bug in LibreOffice 25.2.0.3 I can finally reproduce this bug consistently in LibreOffice 25.2.0.3. To reproduce the bug, do the following steps: 1. Make sure your Mac is set to Dark Mode 2. Delete or move your ~/Library/Application Support/LibreOffice folder 3. Launch LibreOffice 25.2.0.3, go to the Appearance preferences panel, and create a new theme to enable the Customization section 4. In the Customization section, set the following colors to black and restart: - Document background - Calc grid - Calc text 5. Go back to the Customization section and change the theme to Automatic and change the appearance to "Light" and restart 6. Go back to the Customization section and change the appearance to "System" and restart 7. Open a new Calc document and most everything in the document area will be black From the above, it appears to me that the Customization section applies to all themes. Don't know if that is expected or not. If it is expected, maybe a possible solution is to backport the Reset button?
(In reply to Patrick (volunteer) from comment #10) > If it is expected, maybe a possible solution is to backport the Reset button? The reset button cannot be backported as that patch has string changes. I tried back then, but got denied. I will look into the issue, it seems to be a "bad default document colors issue" but cannot say without testing myself.
OK. I just got word today that TDF QA and release engineering aren't going to include any of our patches in LibreOffice 25.2.1 so no need to work around the clock for this bug. Of course I am not happy with their decision. But not much we can do except spread the word that deleting the preferences folder via the Terminal is the current workaround. We'll probably also see duplicate bugs of tdf#165266. That bug (Apple's change in how you get system colors and draw native controls) may look like a theming bug. But fortunately that bug only occurs when the user sets the LibreOffice light/dark appearance to the opposite of the system appearance.
Ok, I found the problem, hard to explain without proper themes documentation. It's a theming issue where the new theme just created doesn't have colors in either the light or the dark palette and when we create the theme and change appearance on the spot, this all black issue happens. This is also because themes were never meant to be used in this raw form. The user is not supposed to create a theme or play around with colors, he is supposed to install one by clicking on the additions button and use that. I will push two patches tomorrow, - the first one explaining the implementation details for themes - and a fix for this bug :)
(In reply to Sahil Gautam (allotropia) from comment #13) > I will push two patches tomorrow, > - the first one explaining the implementation details for themes > - and a fix for this bug :) That is excellent news! Thank you for looking into this. I've got an up-to-date master local build so I should be able to test any patches.
current patch only fixes part of the issue (the UI elements). document font and background still are mismatched when manually overriding the theme, and setting appearance back to system doesn't undo all settings that cause the mismatch. Workaround is to remove the affected settings and switch macOS light/dark mode accordingly. Using LO in a mode that differs still isn't working 100%. sed -i .bak -e '/COLOR_SCHEME_LIBREOFFICE_AUTOMATIC/d' -e '/ApplicationAppearance/d' "$HOME/Library/Application Support/LibreOffice/4/user/registrymodifications.xcu" can be used to reset LibreOffice to default (can also remove the whole profile folder or reset it to default using safe-mode) removing ApplicationAppearance one resets the option to follow the system's light/dark mode, and the COLOR_SCHEME_LIBREOFFICE_AUTOMATIC part removes the incorrectly created custom colorscheme that is unreadable in dark mode.
(In reply to Christian Lohmaier from comment #15) > current patch only fixes part of the issue (the UI elements). This issue is not fixed yet. Only tdf#165266 is fixed. The fix for that bug is to give users an "escape hatch" to get out of document dark mode. The idea is that most macOS users do not use any customize themes but are just trying to get out of document dark mode (i.e. make it like 24.8 again). This issue, in contrast, hopefully affects a much smaller number of users than tdf#165266 hence my push for tdf#165266 to be included in 25.2.1 even without any of @Sahil's other patches. Is changing only the appearance triggering this bug for anyone? I just tried changing appearance and restarting several times with the 24 February 2025 nighty build and I am not seeing this bug get triggered so I am assuming that the fix for tdf#165266 will not cause this bug to occur. But maybe I'm wrong.
Sahil Gautam committed a patch related to this issue. It has been pushed to "libreoffice-25-2": https://git.libreoffice.org/core/commit/e4045146603e3bb64373b60c2675276502cb4f2e tdf#165438 for user created (raw) themes, use default document colors It will be available in 25.2.2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Commit Notification from comment #17) > tdf#165438 for user created (raw) themes, use default document colors > > It will be available in 25.2.2. @steve: this bug has fixed this bug. Thanks @Sahil! Note: his fix won't repair corrupted preferences but it does prevent the corruption from occurring in the first place so once 25.2.2 out, we should hopefully see new occurrences of this bug stop. In the meantime, I am in process of writing up troubleshooting steps in the following LibreOffice wiki page: https://wiki.documentfoundation.org/MacOS/Dark_Mode I was planning on copying much of the text for that wiki page from the following two Reddit posts: https://reddit.com/r/libreoffice/comments/1iw92mz/macos_252_dark_mode_all_black/mesxlr9/ https://reddit.com/r/libreoffice/comments/1iw92mz/macos_252_dark_mode_all_black/mext3u1/ After that, I will investigate tdf#156855.
Sahil Gautam committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/8a1b353e7f0ccaeb7fe179863f27b473f83ca2cb tdf#165438 for user created (raw) themes, use default document colors It will be available in 25.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
*** Bug 165543 has been marked as a duplicate of this bug. ***
@Sahil: what's the status here? "Affected users are encouraged to test the fix and report feedback" but Patrick stated "@Sahil! Note: his fix won't repair corrupted preferences but it does prevent the corruption from occurring in the first place so once 25.2.2 out, we should hopefully see new occurrences of this bug stop." So this does not seem testable. With todays main build I was unable to get into the problematic state.
(In reply to steve from comment #21) > "Affected users are encouraged to test the fix and report feedback" This is just standard text that gets automatically posted when a commit is made. I don't believe this standard text has changed AFAICT and the commit in comment #19 was just copying the fix to another branch. LibreOffice 25.2.0 and 25.2.1 users will need to reset their preferences using Step 3 at the end of the following wiki page: https://wiki.documentfoundation.org/MacOS/Dark_Mode This is why I made such a hard push to get the commit into LibreOffice 25.2.1. But I was unsuccessful and we now have to wait until LibreOffice 25.2.2.
Understood. But if there is no additional patching or action from dev side required this bug here should be set to fixed, no?
*** Bug 165382 has been marked as a duplicate of this bug. ***