Change:
export const selectBackground = registerColor('dropdown.background', { dark: '#3C3C3C', light: Color.white, hcDark: Color.black, hcLight: Color.white }, nls.localize('dropdownBackground', "Dropdown background.")); export const selectListBackground = registerColor('dropdown.listBackground', { dark: null, light: null, hcDark: Color.black, hcLight: Color.white }, nls.localize('dropdownListBackground', "Dropdown list background.")); <del> export const selectForeground = registerColor('dropdown.foreground', { dark: '#F0F0F0', light: null, hcDark: Color.white, hcLight: foreground }, nls.localize('dropdownForeground', "Dropdown foreground.")); </del> <ins> export const selectForeground = registerColor('dropdown.foreground', { dark: '#F0F0F0', light: foreground, hcDark: Color.white, hcLight: foreground }, nls.localize('dropdownForeground', "Dropdown foreground.")); </ins> export const selectBorder = registerColor('dropdown.border', { dark: selectBackground, light: '#CECECE', hcDark: contrastBorder, hcLight: contrastBorder }, nls.localize('dropdownBorder', "Dropdown border.")); export const buttonForeground = registerColor('button.foreground', { dark: Color.white, light: Color.white, hcDark: Color.white, hcLight: Color.white }, nls.localize('buttonForeground', "Button foreground color."));

Discussion:
Hi, Light themes do not have defined at all this variable: And this is used to paint the actual tick in the checkbox. This causes checkboxes to not render ticks in Light+ theme. At the moment, we are using a double variable for this as you can see in the below screenshot. In this way, if the first one fails (as it does here), we cascade to the second one just so the checkboxes can actually render correctly. <img width="570" alt="Screenshot 2022-06-21 at 12 09 57" src="https://user-"This is strange, because in VS Code settings, checkboxes do indeed have a visible check. <img width="580" alt="Screenshot 2022-06-21 at 12 10 56" src="https://user-"I understand that some colours are not available cross-theme (some stuff in input fields for example), but this really looks like bug as there really shouldn't be a reason not to define checkbox foreground. I have checked all of the default Light themes in VS Code, and the variable is not defined in all of them. - - - - In contrast, if I use GitHub official theme for VS Code they have defined it. So they saw it's a bug when they were making a theme, and have included it. This is how it resolves under GitHub Light Default: <img width="348" alt="Screenshot 2022-06-21 at 12 15 36" src="https://user-"<img width="623" alt="Screenshot 2022-06-21 at 12 14 55" src="https://user-"Please include in the default Light themes, painted accordingly. VS Code Version: Version: 1.68.1 (Universal) OS Version: MacOS 12.4 (Running on M1 Pro)
You are correct, the default value of checkboxForeground is null/undefined, and the variable is not defined. For many other colors this can be the case, so your code should be prepared for that. It means the foreground color should default to foreground of a parent composite. Normally we don't generate a css rules in that case and let the normal css lookup rules do their job.

At other place we just set the value to the empty string:
Hm, yes, I understand, but this is a fairly clear cut case that the variable should indeed be defined. Because you could make the same argument for Dark themes - the Dark themed tick of the checkbox could simply default to , yet it is specifically defined. I just feel that something so fundamental as a checkbox, a staple of any interface, should have a tick defined in Light themes. It's just strange to not include it, really feels like a bug rather than an intentional design decision. Because as an opposite example, there are these two variables: ff; ff; Where the same logical thing - a link - will have two separate variables depending on where it shows. If it's in the notification box, it has its own variable, and if it's just a text link, it has another one (even tho they have the same hex value for Dark+ theme). And this is great, this gives us the flexibility to select appropriate sounding variable for whatever UI chunk we are building. You could have easily said here "well, just use textLink-foreground even if it's in the Notifications box", but that wasn't the case, and we have two separate variables. Which is awesome! And generally, I think this is a much better direction - having nice complete sets of variables devoted for each logical zone, rather than (what I feel is) arbitrary removal of one variable from a set.
I don't know why the dark default is set but the white not. That's something to investigate. I believe it's a bug and also the dark should be undefined. Note that we can not default to as we don't know in which view/widget the checkbox. The proper this is really to not give it a foreground color, and let the CSS use the foreground color defined for the surrounding dom node. Yes, agree, having separate color for view is the best and recommended solution. Lets file feature request against the affected views.
Aaah, interesting observation. Can you please give me some clarity why would non-defining both of them be better than actually defining both of them? The reason that comes to my mind is so that the checkbox tick is always in line with some foreground colour, rather than being some arbitrary colour defined by the theme creator.

I suppose that might help with accessibility a bit - having a standardised foreground colour for such cases. But then, on the other hand, shouldn't we (well, you) let theme creators come to this conclusion on their own, and in case you provide native they should just set that hex value to whatever their desired foreground colour is? This gives them some additional flexibility, although the payoff is that they have to actually manually set it. I can basically see some pros and cons for both sides.
I had another look at and I agree that it's inconsistent to have as default for light when all other types use or a specific color. I pushed a fix.