[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) (054a929, 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".