Remove "Website appearance"

In Settings > Language and Appearances, there are [$browser Theme, System theme, Light, Dark].

The whole section should be hidden as it's actually a setting intended to give the theme preference for websites and not only the browser internal pages.

However, RFP makes this useless, and the customization applies only to about pages.

assigned to @pierov

mentioned in issue tor-browser-build#40839 (closed)

assigned to @pierov

added Doing label

removed Doing label

added Needs Information label

So, two things:

1. Firefox RR calls it "Automatic" instead of system now.
2. This setting is misleading anyway for MB/TBB users: RFP forces light theme on sites. We might just hide this section at this point.

added Bug label

added Desktop label

changed the description

For ESR 102:

• default as "Browser Theme" (so the interface follows the theme)
• hide the whole section

This is the behavior of the RR Firefox.

@donuts should we move this to Tor Browser?

Also, I guess that we'll need to create a rollback logic for those who customized this (if any).

Yep I’m happy to follow suit for Tor Browser too. As discussed on IRC, I think “ theme” should be retained as the hidden default while we’re on the ESR 102 train as it seems to provide for the best interaction between the browser and system themes.

As discussed on IRC, I think “ theme” should be retained as the hidden default while we’re on the ESR 102 train as it seems to provide for the best interaction between the browser and system themes.

I don't remember the discussion exactly .

However, the theme can be still changed in the about:addons page.

So, users that customized the theme will be able to change/revert any customization there.

Therefore, as a final decision, I'm suggesting we don't force any change, to prevent users from finding a (possibly unpleasant) "surprise".

As mentioned in chat, I think we will want to reset the preference layout.css.prefers-color-scheme.content-override specifically since we would be removing the UI for this particular preference.

removing the UI for this particular preference

assuming you don't have an extension that also controls this pref :o

https://searchfox.org/mozilla-central/rev/4e6970cd336f1b642c0be6c9b697b4db5f7b6aeb/toolkit/components/extensions/parent/ext-browserSettings.js#275-296

Therefore, as a final decision, I'm suggesting we don't force any change, to prevent users from finding a (possibly unpleasant) “surprise”.

Wfm, I think “Browser Theme” is already the default anyway.

Wfm, I think “Browser Theme” is already the default anyway.

Turns out I didn't catch the possibility of setting a light theme in the browser chrome, and set the website appearance to dark (or vice versa).

So, my suggestion will remove the way to undo this ‍️. We might have to do the pref migration as suggested by Henry.

However, the theme can be still changed in the about:addons page.

about:addons>Themes only shows and implies that the chrome is changing, e.g .look at the images. The section we should hide explicitly says website appearance, so I don't see how users can find a (possibly unpleasant) "surprise" should we hide it

With the UI removed, that means only those that fiddle in about:config can change it, and they deserve a "surprise" for fiddling and RFP to the rescue - or just lock the pref(s)

unless I'm missing something ... sorry for not being on IRC, didn't get the invite

so I don't see how users can find a (possibly unpleasant) "surprise" should we hide it

If we hide and restore layout.css.prefers-color-scheme.content-override, they might find a different theme in about pages (not the end of the world).

or just lock the pref(s)

That isn't a bad idea. If Bug 1788822 added some migration logic, we can lock the pref.

Then when we unlock it when we have Firefox's migration logic and let it do whatever Moz thought.

and RFP to the rescue - or just lock the pref(s)

@thorin just to be clear, I don't think there is a known figerprinting that derives from setting layout.css.prefers-color-scheme.content-override, because this gets further overridden by Resist Fingerprinting.

The only effect it has, with RFP, is to change the content pages not under RFP's scope. So essentially, it just allows the user to change the "about:" page's theme to be different from the chrome theme.

So we don't need to lock the pref as a threat-prevention measure.

sorry for not being on IRC, didn't get the invite

That's a lie . We invited you, the channel is public.

@henry yup, totally get all that but I see my syntax was confusing, I know RFP protects :). The lock comment was a solution to prevent "surprises" - i.e users complaining that they changed the pref and it didn't work

removed Needs Information label

added Next label

moved from mullvad-browser#171 (moved)

changed title from Remove {-Mullvad Browser theme-} to Remove "Website appearance"

changed the description

removed Next label

added Doing label

added Next label and removed Doing label