Description: Applying to light/dark from LibreOffice -> Preferences > View doesn't properly refresh the UI until restart. (macOS) Steps to Reproduce: 1. Enable Dark mode as system setting of macOS 2. Launch Writer 3. LibreOffice -> Preferences > View 4. Appearance: Light Mode 5. Press Apply Actual Results: White font on White background Expected Results: Proper refresh Reproducible: Always User Profile Reset: No Additional Info: Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: e60ef8651cfb30335471d1622e58c13eebc7d58b CPU threads: 8; OS: Mac OS X 13.4.1; UI render: Skia/Raster; VCL: osx Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded
Hello Telesto, Thank you for reporting the bug. Please attach a sample document, as this makes it easier for us to verify the bug. I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the requested document is provided. (Please note that the attachment will be public, remove any sensitive information before attaching it. See https://wiki.documentfoundation.org/QA/FAQ#How_can_I_eliminate_confidential_data_from_a_sample_document.3F for help on how to do so.)
Mo need for a sample document
Created attachment 189219 [details] macos system dark, LO dark, then switched to light but prefs not updated after apply Confirmed -> new Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: b5aaf194866c5e416167cb54d37f9f04dabc5375 CPU threads: 8; OS: Mac OS X 13.5.1; UI render: Skia/Metal; VCL: osx Locale: en-US (en_DE.UTF-8); UI: en-US Calc: threaded
Also in 7.6: Version: 7.6.4.1 (X86_64) / LibreOffice Community Build ID: e19e193f88cd6c0525a17fb7a176ed8e6a3e2aa1 CPU threads: 2; OS: Mac OS X 13.2.1; UI render: Skia/Raster; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
The problem persists and became worse. The dark/light mode does not switch correctly even when restarting LO. In current version, switching to dark and than back to light mode, even when restarting, leaves the canvas black. Only the buttons and the rest of the interface, become light again. This concerns Wirter, Calc and Impress. In dark mode, fonts that are explicitly black (not set on Automatic color), are no longer visible. In Impress, presenter notes are become invisible. Impossible to return to light mode. Setting importance to major, as this seriously impends work. Version: 24.8.1.2 (AARCH64) / LibreOffice Community Build ID: 87fa9aec1a63e70835390b81c40bb8993f1d4ff6 CPU threads: 12; OS: macOS 13.6.4; UI render: Skia/Metal; VCL: osx Locale: fr-CH (fr_CH.UTF-8); UI: en-US Calc: threaded
I have some fixes for macOS in the following patch: https://gerrit.libreoffice.org/c/core/+/182484 The patch does fix some macOS redrawing issues and might have worked in LibreOffice 24.8 and earlier. But the problem I keep running into in LibreOffice 25.2 and higher is that the system colors now get merged with LibreOffice's current theme colors. Theme's like the default Automatic theme have light and dark colors but the theme appears to *not* update its colors when the the light/dark mode changes. I have tried to force the current theme to reload but the only success I have had is disabling the current theme when the light/dark mode changes. Not sure how this problem can be solved.
(In reply to andre78ch from comment #5) > The problem persists and became worse. The problem described is a different issue though, but out of interest: Did you change the default because you actually want to have LO's menus be in light/dark opposing of your macOS settings, or only to verify/test this bug? > The dark/light mode does not switch correctly even when restarting LO. > In current version, switching to dark and than back to light mode, even when > restarting, leaves the canvas black. Yep, that's bug#165266 > > This concerns Wirter, Calc and Impress. In dark mode, fonts that are > explicitly black (not set on Automatic color), are no longer visible. > In Impress, presenter notes are become invisible. Impossible to return to > light mode. Setting importance to major, as this seriously impends work. > > Version: 24.8.1.2 (AARCH64) / LibreOffice Community > Build ID: 87fa9aec1a63e70835390b81c40bb8993f1d4ff6 > CPU threads: 12; OS: macOS 13.6.4; UI render: Skia/Metal; VCL: osx > Locale: fr-CH (fr_CH.UTF-8); UI: en-US > Calc: threaded
oups, wasn't done writing the comment – workaround is to use the light application theme or to reset the corresponding settings from the user-profile, then you actually get the default behavior again. A command you could use to reset the relevant settings is (make sure to have it all in a single line): sed -i .bak -e '/COLOR_SCHEME_LIBREOFFICE_AUTOMATIC/d' -e '/ApplicationAppearance/d' "$HOME/Library/Application Support/LibreOffice/4/user/registrymodifications.xcu" the COLOR_SCHEME_LIBREOFFICE_AUTOMATIC values are the cause of having black canvas/are incorrectly applied and not cleared when switching back to follow the system's theme, and the ApplicationAppearance one is the system/light/dark toggle that will be reset to system. Anyhow, that's the other issue.
(In reply to Christian Lohmaier from comment #8) > Anyhow, that's the other issue. Correct. This issue is a combination of bugs in the native macOS code and the new theme colors. FWIW. This bug was filed before the new themes feature was added. Specifically, this bug was for when the macOS light/dark preference is changed while running LibreOffice. Then, starting in LibreOffice 25.2, this bug is also occurs when changing light/dark mode in the LibreOffice Appearance panel and not restarting immediately. Although I can't test this, I think my patch in comment #6 (minus my hacky theme calls) might actually fix the original bug in LibreOffice 24.8. Haven't had time to rebuild and test that though. The problem for LibreOffice 25.2 (and what I think testers say is worse) is that my fix works but only if I basically disable the Automatic theme color (i.e. run in a themeless mode like 24.8 did). The themes feature merges its colors with the native colors and but the current theme (Automatic is the default) does not switch it colors and so when you switch light/dark mode (however you choose to do it) while LibreOffice is running, the current theme's colors remain stuck in the previous mode until restart and LibreOffice becomes nearly unreadable do to a mixture of the right native colors and the now invalid current theme colors. I really think ThemeColors needs a call to dump its cached values and reload with the current light/dark mode. That is the piece that is missing IMHO.
(In reply to Patrick (volunteer) from comment #9) > I really think ThemeColors needs a call to dump its cached values and reload > with the current light/dark mode. That is the piece that is missing IMHO. Forgot to mention that this might be the cause of tdf#165266 so adding that as a dependency of this bug. The problem is how to enable vcl to call directly to the ColorConfig object in svtools. Can't link vcl to svtools as svtools is already linked to vcl. Probably we can use vcl's "notify listeners" to call into the ColorConfig object. But the key here is that when the macOS light/mode preference is changed, we will first notice it in the native vcl code and then need to "bubble up" that change to the rest of the LibreOffice code. In contrast, changing the light/dark mode in LibreOffice's Appearance panel works in the opposite direction: the cui code pushes the change down to vcl.
(In reply to Patrick (volunteer) from comment #10) > Forgot to mention that this might be the cause of tdf#165266 so adding that > as a dependency of this bug. The problem is how to enable vcl to call > directly to the ColorConfig object in svtools. Can't link vcl to svtools as > svtools is already linked to vcl. Got this working in the latest version of my patch: https://gerrit.libreoffice.org/c/core/+/182484 Probably will need to be tested on Windows and Linux as well.
Patrick Luby committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/93574e7a581bc9d0a06e83f2bf1e1caab093ae69 Partial: tdf#156855 update native and LibreOffice dark mode states 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 (12 March 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
Patrick Luby committed a patch related to this issue. It has been pushed to "libreoffice-25-2": https://git.libreoffice.org/core/commit/86bc37a40be72539f98198bc6c1c92fed20a3fd7 Partial: tdf#156855 update native and LibreOffice dark mode states 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.
Version: 25.8.0.0.alpha0+ (AARCH64) / LibreOffice Community Build ID: 7b9e27da2033192c628b23e4e1686209e951dadb CPU threads: 12; OS: macOS 15.3.2; UI render: Skia/Metal; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded Verified - works nicely. Two questions: 1. why do users have to "Apply" in the first place? I understand this may be useful for some cases, but for the Appearance this is so straight forward: user click -> user see. Why force them to click "Apply"? At least that's how macOS system settings handles Appearance changes and I have to say it is the most straigh-forward and sane way. 2. why is a restart dialog still shown? After changing Appearance and clicking "Apply" after closing the dialog with "OK" there is another dialog to "Restart LibreOfficeDev". Is that restart still needed when only appearance has changed? Thoughts on this? Do we need follow-up issues?
Auto switch is still a bit wonky on Windows os/DE builds when switching DE between 'Dark' color mode and 'Light' color mode (Settings -> Personalization -> Colors). But, the 'Reset All' button on the Appearance -> Theme panel for the default 'Automatic' theme is now more completely regenerated, without need to clear user profile. Although it does still prompt and require 'Restart LibreOffice' it is now a pretty complete toggle. =-testing-= on Windows Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: bff3d755c8c11721054f4ff40a3d5f723b0c6b96 CPU threads: 28; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded Sidebar issue: unfortunately, seems the 'Reset All' will destroy an applied Appearance theme other than the Automatic. Use it with care as removing and installing the appearance themes remains a manual action in users LO profile.
(In reply to V Stuart Foote from comment #16) > =-testing-= > on Windows > Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community > Build ID: bff3d755c8c11721054f4ff40a3d5f723b0c6b96 > CPU threads: 28; OS: Windows 11 X86_64 (build 26100); UI render: > Skia/Vulkan; VCL: win > Locale: en-US (en_US); UI: en-US > Calc: CL threaded This patch is only enabled on macOS so I doubt it solves any color issues on Windows or Linux. This bug is a macOS-only bug that started occurring when macOS introduced native Dark Mode. Specifically, my patch fixes the wrong system colors being used when the user changed light/dark mode in macOS System Preferences while LibreOffice is running. When @Sahil added the new theme code, it just made this bug more obvious. Before my patch, the order of operations between macOS and LibreOffice was incorrect and some of the previous light/dark mode's colors would be used instead of the new system colors. Maybe the Windows and Linux developers might be able to use some or all of my patch. I left a "Note for Windows and Linux" at the very bottom of the following patch: https://git.libreoffice.org/core/+/93574e7a581bc9d0a06e83f2bf1e1caab093ae69%5E%21
(In reply to Patrick (volunteer) from comment #17) > > This patch is only enabled on macOS so I doubt it solves any color issues on > Windows or Linux. > Oh sorry, looked like you'd touched colorcfg.cxx and its .hxx in addition to the osx vcl workup. Missed you'd put the settings.cxx under an ifdef for MACOSX. Guess Sahil has got it... Thank you though for plugging away at this--the color theming is a major enhancement to the UI!
Patrick Luby committed a patch related to this issue. It has been pushed to "libreoffice-25-2-2": https://git.libreoffice.org/core/commit/81bc7b708de0d455d7f64bf2ec40090ea08cf0c5 Partial: tdf#156855 update native and LibreOffice dark mode states 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.