Description: The new version (25.x) has messed up the background colors of documents. If I try to change that in Preferences, the Preferences are not readable because the typeface is now white on a white background. Steps to Reproduce: Just open a word document in the newly installed version 25. Every background color is different - and not in a pleasant way. Actual Results: Just open a word document in the newly installed version 25. Expected Results: I do not need background colors to look exactly like they used to in version 24, but this looks just terrible. (Resetting user profile to factory settings does not make any difference.) Reproducible: Always User Profile Reset: Yes Additional Info: Have been using LO for many years and never had an issue. Why does this have to look so user-unfriendly? I can't imagine any user will like it and like to work with it.
Created attachment 199217 [details] Screenshot of messed-up interface
You look to have toggled the Appearance theme panel for 'Automatic' theme from 'System' to 'Light'. At the moment, best to download and enable one of the Appearance themes (the mustard download star). That will apply a set of colors that should be functional with any of the three RB settings 'System' (following os/DE) 'Light' or 'Dark' Getting back to default Automatic theme can be done, but is fiddley. Simplest to delete your user profile. @Heiko, @Sahil your both up on macOS systems at this point. Any issues for you applying and manipulating the Appearance theme extensions, or of the default Automatic theme responding to Light|Dark or System reported color theming?
Well I planned to buy one at the end of this month, but guess that would be too late. I will get one by tomorrow max, then will push some patches to remedy the situation.
(In reply to Sahil Gautam (allotropia) from comment #3) > Well I planned to buy one at the end of this month, but guess that would be > too late. I will get one by tomorrow max, then will push some patches to > remedy the situation. Cool! Maybe reach out to Patrick L. to compare notes.
(In reply to V Stuart Foote from comment #2) > You look to have toggled the Appearance theme panel for 'Automatic' theme > from 'System' to 'Light'. I can reproduce this. If the Appearance preference is set to System, all the colors are readable (I tested both system light and dark modes). Only when the Appearance preference is set to the opposite of the system setting does the bug occur: Version: 25.2.0.3 (AARCH64) / LibreOffice Community Build ID: e1cf4a87eb02d755bce1a01209907ea5ddc8f069 CPU threads: 8; OS: macOS 15.3; UI render: Skia/Metal; VCL: osx Locale: en-CA (en_CA.UTF-8); UI: en-US Calc: threaded
(In reply to V Stuart Foote from comment #2) > Getting back to default Automatic theme can be done, but is fiddley. > Simplest to delete your user profile. I can confirm that quitting LibreOffice and then deleting my LibreOffice preferences folder will restore LibreOffice to a readable state although you will be stuck using whatever light or dark mode your Mac is set to. For any other users that are experiencing this bug, use the following steps to delete your LibreOffice preferences folder: 1. Quit LibreOffice 2. Go to the Finder and select the Go > Go to Folder menu item 3. Paste the following path in the dialog that appears and press the Enter key: ~/Library/Application Support/LibreOffice 4. There should be a subfolder in the above folder named "4". Move that folder to the Trash. 5. Restart LibreOffice
*** Bug 154916 has been marked as a duplicate of this bug. ***
Same problem here. I thought it had something to do with all the themes disappearing but seems like it’s a bigger bug. I’ve reverted to the last version of 24 to correct it.
@Sahil I might have an idea what is causing this bug. I think it is because native controls (buttons, listboxes, scrollbars, etc.) and native system colors draw using system light/dark mode colors. So when the user sets the LibreOffice preference to the opposite of the system light/dark mode preference, we get a mix of both light and dark mode colors. On master, with system dark mode and LibreOffice light mode, the background in the Preferences dialog is nearly black even after restarting LibreOffice and the text is nearly white. I believe both the background and text color are from system colors. I see some code in vcl/osx/salframe.cxx that sets the native light/dark mode at runtime so I'll see if maybe that is failing.
(In reply to Patrick (volunteer) from comment #9) > I see some code in vcl/osx/salframe.cxx that sets the native light/dark mode > at runtime so I'll see if maybe that is failing. I think I found the problem: native system colors don't change even when LibreOffice changes the light/dark mode. I believe this worked in the past but after some online searching, I found that Apple recently deprecated +[NSAppearance setCurrentAppearance:] which I assume is what updates the native system colors. So, it looks like Apple's replacement for the deprecated call is wrapping all of our system NSColor requests in the new -[NSAppearance performAsCurrentDrawingAppearance:] call like below: [[NSAppearance appearanceNamed: NSAppearanceNameAqua] performAsCurrentDrawingAppearance:^() { NSColor *pColor = [NSColor windowBackgroundColor]; }]; I will try converting all of the "[NSColor " calls this week and see what else is still broken.
OK. I got a fix. @Sahil if you have a Mac, can you test it out?: https://gerrit.libreoffice.org/c/core/+/182074
(In reply to Patrick (volunteer) from comment #11) > OK. I got a fix. @Sahil if you have a Mac, can you test it out?: > > https://gerrit.libreoffice.org/c/core/+/182074 Yes, I got the mac last Tuesday, would test it in a few hours (busy with college).
Patrick Luby committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/48125efbd7bf370981d48e4a8d0ce7fbaf1857e1 tdf#165266 Force NSColor and native controls to use effective appearance 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.
I have committed a fix for this bug and the fix should be in tomorrow's (25 February 2025) nightly master builds: https://dev-builds.libreoffice.org/daily/master/current.html Note for macOS testers: the nightly master build installer does not overwrite any LibreOffice official versions. Instead, it will be installed as a separate application called "LibreOfficeDev" in the /Applications folder. Because this is a "test" build, you will need to do the following steps before you launch the LibreOfficeDev application: 1. Go to the Finder and navigate to the /Applications/Utilities folder 2. Launch the "Terminal" application 3. Paste the following command in the Terminal application window and press the Return key to execute the command: xattr -d com.apple.quarantine /Applications/LibreOfficeDev.app
So there is one case that I am unable to fix: you must restart LibreOffice after changing the appearance preference in LibreOffice's Options dialog. Otherwise everything is redrawn with a mix of light and dark mode colors until the next restart of LibreOffice. @Sahil: do you see this on Windows or Linux? On macOS, changing the preference *does* call our native system colors changed handler but I don't know what is needed to force all LibreOffice windows to refetch and repaint with the new system colors. Seems the application code higher up from vcl is caching colors and calling Window::Invalidate() isn't enough to force Writer, Calc, etc. to update the colors it uses.
Patrick Luby committed a patch related to this issue. It has been pushed to "libreoffice-25-2": https://git.libreoffice.org/core/commit/7c659f8ac950284a4094b97a73e2ce5a5a6b86e5 tdf#165266 Force NSColor and native controls to use effective appearance 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.
Thanks for looking into this nuisance, Patrick. Confirming that with 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 I am asked to restart later or now when closing preferences and preferences not changing to unreadable state (light / dark mix). So the issue here is resolved. As for the remaining issue of LibreOffice not instantly adapting the user theme on macOS, as is expected and seen in other macOS apps when changing system theme, I think that is tracked as https://bugs.documentfoundation.org/show_bug.cgi?id=156855 The problem concerns both changing macOS System Settings > Appearance or LibreOffice > Preferences > Appearance.
Wondering if this regression is related to the recent changes: 165438
How I wish bugzilla allowed 5 minute editing... https://bugs.documentfoundation.org/show_bug.cgi?id=165438
Patrick Luby committed a patch related to this issue. It has been pushed to "libreoffice-24-8": https://git.libreoffice.org/core/commit/0e814bd05c469be795a0227007af871d053c450a tdf#165266 Force NSColor and native controls to use effective appearance It will be available in 24.8.6. 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 Patrick (volunteer) from comment #15) > So there is one case that I am unable to fix: you must restart LibreOffice > after changing the appearance preference in LibreOffice's Options dialog. > Otherwise everything is redrawn with a mix of light and dark mode colors > until the next restart of LibreOffice. > > @Sahil: do you see this on Windows or Linux? On macOS, changing the > preference *does* call our native system colors changed handler but I don't > know what is needed to force all LibreOffice windows to refetch and repaint > with the new system colors. Seems the application code higher up from vcl is > caching colors and calling Window::Invalidate() isn't enough to force > Writer, Calc, etc. to update the colors it uses. Yes this happens on Windows builds to 25.2.1, bug 164399, which Sahil had tweaked with https://gerrit.libreoffice.org/c/core/+/179041 which is still open. But maybe OBE as the 'Light' | 'Dark' radio button toggle now at 25.8 triggers the LibreOffice restart. Desired in my opinion for consistency. But the non-restart document (vs. UI) color mode toggle, .uno:ChangeTheme action is broken. That is bug 165121 which Sahil has on his list, but is a UX issue for the new theme framework. Not sure what is the best direction cross platform, to require restart or allow document appearance to toggle without it. But the UI does need to be consistent cross platform so we can get it documented into help and user guides.
Patrick Luby committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/1553e8c2b245b2226454e5fdacdf77da58fe0a18 tdf#165266 fix conditionals that limit -[NSApp setAppearance:] calls 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.
Patrick Luby committed a patch related to this issue. It has been pushed to "libreoffice-24-8": https://git.libreoffice.org/core/commit/1a0a577b77a52f19d44b79b73c6fb84a5430157a tdf#165266 fix conditionals that limit -[NSApp setAppearance:] calls It will be available in 24.8.7. 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.
Patrick Luby committed a patch related to this issue. It has been pushed to "libreoffice-25-2": https://git.libreoffice.org/core/commit/2170d9a8c6aa05aaecd763074311358abc88799c tdf#165266 fix conditionals that limit -[NSApp setAppearance:] calls It will be available in 25.2.3. 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.
Patrick Luby committed a patch related to this issue. It has been pushed to "libreoffice-25-2-2": https://git.libreoffice.org/core/commit/0f7e7a719c5955203f3cdc0ca2c0f1d33cd233af tdf#165266 fix conditionals that limit -[NSApp setAppearance:] calls 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.
Patrick Luby committed a patch related to this issue. It has been pushed to "libreoffice-24-8-6": https://git.libreoffice.org/core/commit/d69ca3240f7611961ff50882391ae45fde5be78f tdf#165266 fix conditionals that limit -[NSApp setAppearance:] calls It will be available in 24.8.6. 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.