Open Bug 1818827 Opened 2 years ago Updated 1 years ago

Default system theme content colors don't match light theme colors (contentTheme.js)

Categories

(Firefox :: Firefox View, task, P3)

task

Tracking

()

People

(Reporter: aminomancer, Unassigned)

References

Details

(Whiteboard: [fidefe-firefox-view])

Attachments

(4 files)

STR

  1. Go to about:addons
  2. Make sure system theme is enabled and your OS color scheme is not set to dark mode
  3. Go to about:firefoxview for example (other pages loading contentTheme.js have the same problem)
  4. Confirm the background color is white, #fff
  5. Go back to about:addons
  6. Change the theme to Light
  7. Go back to about:firefoxview
  8. Confirm the background color is #f9f9fb
  9. Look at the CSS properties on the page
  10. There's no --newtab-background-color or any other custom properties from contentTheme.js, I am guessing the intention is that the system theme's light mode is equivalent to the internal CSS color values from common-shared.css, because the manifest only has a dark mode.

Actual

Different colors depending on system theme-light mode vs. built-in light theme

Expected

The system theme's light mode should look the same as the light theme, like it does everywhere else (except pages that load contentTheme.js, like about:newtab)

I think this color should be #fff, so the themes should be updated. It seems like the figma designs use #fff, but implementation has #f9f9fb because the theme is overriding it. We suspect there may have been some confusion, where in light mode, the Tab Pickup card is white and the background is white, but in dark mode, the Tab Pickup card is much lighter than the page background.

We think this might be related to the fact that, when the light theme is enabled, the card and background actually are different colors. We'd like them to always be the same color (except in HCM), because we need to ensure that feature callouts on the page will have sufficient contrast with both the tab pickup card and the overall page background. Since the cards already have borders and don't cover anything else on the page, they can get away with being the same color as the page background. But the feature callouts overlap content so they need more contrast.

Firefox View and the New Tab page use intentionally slightly different background colors - for better or worse. But there shouldn't be any difference between the Light theme and the System theme in light (OS appearance) mode.

(In reply to Sam Foster [:sfoster] (he/him) from comment #1)

Firefox View and the New Tab page use intentionally slightly different background colors - for better or worse. But there shouldn't be any difference between the Light theme and the System theme in light (OS appearance) mode.

With Light theme enabled, both about:newtab and about:firefoxview have #f9f9fb. But with system theme (light mode), I see #f9f9fb on about:newtab, but #fff on about:firefoxview. I'm not sure which is correct, but FWIW the Figma prototypes all seem to depict #f9f9fb. I mentioned in the first comment how the system theme's manifest doesn't have a light mode, so the colors will be drawn from stylesheets in that case. But it works on about:newtab because about:newtab has #f9f9fb hard-coded, while about:firefoxview doesn't, and falls back to --in-content-page-background.

So the fix for this bug may just involve setting an initial value for --newtab-background-color on the root element, but I'm not sure what that value should be.

Hi Sarah and Josh! I asked around about who would have the most knowledge here and your names came up. To summarize, we encountered a discrepancy in Firefox View's background color between the default "System theme — auto" theme (system light mode enabled) and the "Light" theme.

I gathered from the rest of the browser that, when system light mode is enabled, "System theme — auto" is supposed to look identical to the "Light" theme. The "Light" theme would just be a way for the user to enable this light appearance all the time, in cases like on macOS where system light mode is not necessarily always enabled. And these two themes do look the same as far as the browser chrome and other system pages go. The only exception seems to be the background color on Firefox View — #fff for system theme, #f9f9fb for light theme.

Normally, that color comes from the theme/colorway, but with light mode enabled, the system theme does not provide any lightweight theme properties. I assumed from that that it's basically the null option, with Firefox's internal stylesheets providing the values. That works on about:newtab, because its internal stylesheets specify a default value that matches the "Light" theme. But on Firefox View, the background color is given by var(--newtab-background-color, var(--in-content-page-background)). So if there is no --newtab-background-color, it defaults to the common system page background color, which is #fff. So that means the "System theme — auto" and "Light" themes are not actually the same on Firefox View.

I initially assumed it was just an implementation oversight, since the difference between #f9f9fb and #fff is so subtle. I figured #f9f9fb was the correct value and we were just missing this value in the internal stylesheet, because about:newtab has #f9f9fb for both themes. But after discussing with Gabrielle and reviewing several designs in Figma, I'm less certain about the design intention. In some designs, the background is #fff, but in others, the background is #f9f9fb.

It's a subtle distinction but it does affect whether the setup card (which is #fff) will be the same color as the page or slightly different. And if that contrast between card and page (#fff on #f9f9fb) was part of the initial designs, then it might explain why, for the dark theme specifically, the card is significantly lighter than the page (#42414d on #2b2a33). And because the card already uses our lighter color #42414d, we couldn't reuse it for Feature Callouts (the little messaging boxes that appear on Firefox View pointing to the cards) and maintain contrast, so we had to use a much darker background for those than the designers intended (#1c1b22). Which meant the callout's button had to be lighter than the callout (#2b2a33), since the callout was already so dark in terms of absolute value. But what was actually intended was for the callout's button to be darker than the callout, but then become lighter on hover.

So that contrast between the card and the page bg had a ripple effect on all the callout colors, and if we could get rid of the contrast, so the card and page are the same color regardless of theme, then we could bring the Feature Callout colors into alignment with the Figma designs. But I think that ultimately depends on whether we intended for the page and the setup card to have the same background color in light mode.

So I wonder if maybe UX consciously chose a different background color for Firefox View. I think it's safe to assume we didn't mean for "System theme — auto" and "Light" theme to yield different results, but if only one of them is correct, which one is correct? #f9f9fb or #fff?

Thanks!

Flags: needinfo?(sclements)
Flags: needinfo?(jberman)

Hey Shane,

I'm not sure I can answer your question entirely except to say that we had to use color-mix quite a bit on Fx View in order to pass our color contrast ratios in different themes, so adjusting any one variable might impact a different variable for which that one is an input and cause us not to make color contrast. For that reason, the easiest thing to do would just be to use a different variable. It's also worth keeping in mind that some of the color system is actually different for light and for dark themes. Again, we needed to do this to be able to pass color contrast for accessibility. I think that might be part of what's happening here but Sarah would be able to better answer that question. The Figma files are directionally correct but honestly they are not your source of truth. It's impossible to replicate things like color-mix in figma so at a certain point we stopped looking to figma as a source of truth for color and started relying on code.

In terms of UX intent, this UI was extremely difficult to build because of how themeable it needs to be. I think our intention was to be in the ballpark of our original designs but to pass WCAG AA contrast guidelines everywhere. We definitely compromised some of the original color decisions in order to be more accessible.

Flags: needinfo?(jberman)

Hi Shane,

I'm trying to dig into my memory since this work was done 7 months ago and unfortunately a lot of conversations Josh and I had were based on slack, trying to figure out how to make the stylesheet for Firefox View flexible enough to handle colorway closet themes. That required a lot of collaborating and tweaking on the fly and I do echo what Josh said about any figma specs you may have seen for View - those shouldn't be deemed the source of truth especially since early mocks were done by a contractor and didn't incorporate awareness of system themes and colors. I do recall a conversation about a default light theme color in an early firefox view spec that didn't match new tab, so we did try to aim for that where it made sense (also see https://bugzilla.mozilla.org/show_bug.cgi?id=1761782#c2).

So I'm not quite sure what the ask is here. You did file this in the themes component, but in your first comment you also mention figma specs (firefox view?) and what you think is an inconsistency with that page in regards to light vs os-default theme and how it relates to the feature callouts.

So that contrast between the card and the page bg had a ripple effect on all the callout colors, and if we could get rid of the contrast, so the card and page are the same color regardless of theme, then we could bring the Feature Callout colors into alignment with the Figma designs. But I think that ultimately depends on whether we intended for the page and the setup card to have the same background color in light mode.

I don't think we can get rid of the contrast between the card and page if we're still trying to accommodate the colorways closet themes (which I think we are, for anyone who had it saved). I think some of the colorways manifests are considered 'light' themes so we'd have to be careful about changing the card background vs page background. Perhaps we could chat more about this over a zoom call? Visuals would probably help.

Flags: needinfo?(sclements)

I'll post some screenshots of Firefox View with different themes enabled, and then some screenshots of about:newtab with the same themes for comparison.

Here is Fx View with "Light" theme enabled

Fx View with "System theme — auto" theme enabled

about:newtab with "Light" theme enabled

about:newtab with "System theme — auto" theme enabled

The severity field is not set for this bug.
:dao, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(dao+bmo)
Severity: -- → S4
Flags: needinfo?(dao+bmo)
Priority: -- → P3

Shane and I talked about this and what would probably make sense is to ensure the light and OS themes align by making this change:

--fxview-background-color: var(--newtab-background-color, #F9F9FB);
--fxview-text-primary-color: var(--newtab-text-primary-color, rgb(21, 20, 26));

If however, we didn't to do that we would have to change the ntp_background to #FFFFFF for light theme, and continue to use the in-content colors as fallback colors.

Type: defect → task
Component: Theme → Firefox View
Whiteboard: [fidefe-firefox-view]
See Also: → 1831299
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: