[themes] Dark mode detection silently breaks with settings sync

[arennow]

Issue Type: Bug

The majority of the time that I switch between my MacBook Pro and my Mac mini, the dark-mode detection is "wrong". As in, the switch is still enabled, but it hasn't actually worked correctly. If I go to settings and toggle it off and then back on, it'll correctly change the color scheme of VSCode to match the system.

VS Code version: Code 1.56.2 (Universal) (054a9295330880ed74ceaedda236253b4f39a335, 2021-05-12T17:44:30.902Z) OS version: Darwin arm64 20.4.0

System Info

|Item|Value| |---|---| |CPUs|Apple M1 (8 x 24)| |GPU Status|2d_canvas: enabled
gpu_compositing: enabled
metal: disabled_off
multiple_raster_threads: enabled_on
oop_rasterization: enabled
opengl: enabled_on
rasterization: enabled
skia_renderer: disabled_off_ok
video_decode: enabled
webgl: enabled
webgl2: enabled| |Load (avg)|2, 2, 2| |Memory (System)|16.00GB (0.16GB free)| |Process Argv|--crash-reporter-id abcc2a75-3c7b-4b31-a5cf-d2816f3ff1fb| |Screen Reader|no| |VM|0%|

Extensions (9)

Extension|Author (truncated)|Version ---|---|--- language-x86-64-assembly|13x|3.0.0 better-toml|bun|0.3.2 html-leaf|Fra|0.2.1 vscode-clang|mit|0.2.4 cargo|pan|0.2.3 rust|rus|0.7.8 xcode-keybindings|ste|1.9.0 vscode-lldb|vad|1.6.3 linkerscript|Zix|1.0.1

A/B Experiments

``` vsliv368:30146709 vsreu685:30147344 python383cf:30185419 pythonvspyt602:30300191 vspor879:30202332 vspor708:30202333 vspor363:30204092 vswsl492:30256859 vstes627:30244334 pythonvspyt639:30300192 pythontb:30283811 pythonvspyt943:30300582 vspre833:30267464 pythonptprofiler:30281270 vshan820:30294714 pythondataviewer:30285071 vscus158:30286553 vscgsv2ct:30301613 vscorehovct:30302760 bridgeflightcf:30302070 vscod805cf:30301675 ```

[aeschli]

Are you using settings sync? Could it be that we sync the theme setting from the other machine that has a different dark/light mode?

[arennow]

I am, yes (I meant to mention that), but in my mind, the "automatically detect system color scheme" setting is the thing that's being synched, and each instance of the app should make appropriate choices based on that. Is there also a "light/dark mode" setting that's being synched?

[aeschli]

We have a setting "workbench.colorTheme" that contains the current theme. There's also a setting window.autoDetectColorScheme, that when on, sets the "workbench.colorTheme" accordingly. It does that when there's a OS scheme change event from the OS or on restart.

The problem you are seeing is that workbench.colorTheme comes in from settings sync, invalidating the theme chosen based on 'window.autoDetectColorScheme'

You can workaround this by setting this:

    "settingsSync.ignoredSettings": [
        "workbench.colorTheme"
    ]

With the way we do this now, it'd difficult to fix that on our side. We currently permit the user to manually change the theme, even if does not match the current OS theme.

The fix would be go away from the boolean settings window.autoDetectColorScheme and instead have workbench.colorTheme set to autoDetectedColorScheme. That could then by synced across machines.

[arennow]

Well, that's good to know. I'll go ahead and make that change and improve my life 0.7%. Thanks!

We currently permit the user to manually change the theme, even if does not match the current OS theme

I definitely understand why this has existed historically, but I wonder how many people specifically want, e.g. a light-themed OS and a dark-themed editor.

Anyway, your proposed fix seems like it would work out great for everyone. I have no idea how deprecated settings work with synching, but that's your problem, not mine :P

[aeschli]

Thanks for trying out the workaround!

[aaronadamsCA]

I'm going to add my long-standing problem to this issue, since "how window.autoDetectColorScheme works" is its shared root cause.

If the OS switches from light to dark while Codespaces is stopped, it becomes a challenge to start the container again. As far as I can tell, my local settings.json is mapped into the Codespaces container, and is changed while the container is stopped. This unexpected state of "a file changed while the container was stopped" is not handled well.

While that's probably worth fixing, it would be an edge case if it weren't for the behaviour of window.autoDetectColorScheme. If it just caused workbench.colorTheme to be ignored in favour of workbench.preferredLightColorTheme and workbench.preferredDarkColorTheme, the issue would be resolved.

[ELLIOTTCABLE]

This is also an issue with workspaces: when you create a workspace and add autoDetectColorScheme settings to that workspace ...

"window.autoDetectColorScheme": true,
"workbench.preferredDarkColorTheme": "Nord Deep",
"workbench.preferredLightColorTheme": "Ayu Light Bordered",
"workbench.colorTheme": "Nord Deep",

… loading the workspace won't "update" the current dark/light status from the O.S.; instead, it will open in whatever state it was previously in when closed (because the workbench.colorTheme is hard-coded into the .code-workspace file, now.)

I think the correct solution is something like #91231, or what @aeschli suggested above — having a way to 'set' the workbench.colorTheme to "undefined, please go look in workbench.preferred… instead".