Legibility problem with Theme select in Windows Firefox

[InertSloth]

What version of starlight are you using?

0.35.3

What version of astro are you using?

5.13.7

What package manager are you using?

pnpm

What operating system are you using?

Windows 11 Pro

What browser are you using?

Firefox 142.0.1 (64-bit)

Describe the Bug

In firefox, the theme select menu while in dark mode has numerous problems. It is fine in light mode. The background around the options is white when it should be dark. The text on the current hover / checked option is white, instead of inverted.

See the following screenshot. This is true of all new starlight installs and has for at least since starlight 0.35.2, but likely much older. You can see it on the official https://docs.astro.build astro docs website as well.

My workaround was to make a custom css file in my install to fix it with the following:

	[data-theme='dark'] starlight-theme-select {
		& select,
		& select option,
		& select option:checked {
			background-color: var(--sl-color-gray-6);
			color: var(--sl-color-text);
		}
		
		& select option:hover {
			background-color: var(--sl-color-accent-high);
			color: var(--sl-color-text-invert);
		}
	}

My workaround produces the following in firefox dark mode. I did not extensively test this workaround in other browsers:

While I believe it maintains functionality in light mode.

Link to Minimal Reproducible Example

https://astro.new/latest/preview/starlight-basics/

Participation

• [ ] I am willing to submit a pull request for this issue.

- 🦥

[delucis]

Thanks for the issue @InertSloth! I think this is the same thing as being discussed here: https://github.com/withastro/starlight/discussions/3180#discussioncomment-13050549

It’s a quite specific bug with Firefox on Windows that’s hard for us to fix generically because it would require us to set a solid background colour on the <select>, which may or may not match the nav bar, breaking the design. HiDeoo suggests a similar workaround to your CSS there:

One workaround could be to set the expected background color of the <select> element rather than transparent […] Altho, this would force us to set the background color of the <select> element everywhere we use one, as the expected background color is not the same everywhere and can also change between screen sizes. This would also not work when the expected background color is actually transparent (e.g. in the Starlight documentation homepage).

Given this, I think it may be something we can’t do anything about and need to wait until Firefox fix their upstream bug. But your workaround could be applied using custom styles in your site, I think.

[InertSloth]

note: I really apologize, I have a lot of difficultly communicating, especially writing succinctly and non-emotionally.

Interesting, I had searched for open issues, but ironically not open discussions. Thanks for taking a look at this @delucis and responding.

This is a pretty glaring (pun intended) bug for all viewers on this platform (win+firefox) that affects all default installs, including the astro docs website itself. Especially for what may be the very first action someone takes when landing on a new site (though auto reduces this drastically).

If I understand correctly @HiDeoo mentioned it might be too hard to fix the bug on all selects the user might ever use on their site, and that is likely true. We may be able to just fix it for the theme component in the header though.

Reading that thread it is obvious there is a lot going on I'm not aware of or understand, just being a beginner, like the background changing based on width or mobile use, but if it is, wouldn't it be a case of finding each one and adding the select color fix with those selectors each time? We can target only the theme selector in dark mode as I've done in my workaround.

After all if that is the case, and as I've demonstrated with my workaround, if there are all these edge cases to track down, I myself failed to be aware of them making my fix and actually potentially caused problems elsewhere. So having experts do it would be preferable to having every installer do it who may not be as knowledgeable (like me) of all the different cases they need to cover.

Also, If as you suggest this is something that installers should fix in custom styles, then every single install that cares about windows firefox needs to do to fix the default theme.

Even if starlight doesn't ship a fix, it should document this as one of the first thing every single install needs to do. Is that too strong? I think that makes the strongest case we can make for why this should be fixed upstream and not in installs.

If we think the fix is too hard to deploy in a way that hits all browsers and platforms, but still worth fixing for windows firefox users (I don't have the stats sadly, especially for more technical websites like documentation sites astro produces, but from what I can tell it should be >~3-5% baseline), we could potentially use a more temporary brittle fix while we wait. It may break the future and need to be adjusted though:

I'm not an expert in this, but something that hacky targets firefox + windows like:

@-moz-document url-prefix() {
  @media screen and (-moz-platform: windows) {
  }
}

Since if it fails, we are left with the same broken behavior we currently have, it certainly wouldn't make things worse.

Thoughts?

- 🦥

[InertSloth]

I have since written a guide on how to apply this fix, which I encourage every single Astro Starlight project to do; so that it isn't visibly broken on every single Astro Starlight site on Firefox for Windows that uses a variant of the default theme.

• ✂ Github Snippet — Astro Starlight theme selector Firefox Windows Fix

- 🦥