Closed Bug 1670017 Opened 4 years ago Closed 4 years ago

Installed light theme not recognized as light

Categories

(Thunderbird :: Theme, defect)

Product:
Thunderbird
Component:
Theme
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: mvalle, Assigned: TbSync)

References

Details

Attachments

(5 files)

See text
40.20 KB, image/png
Details
signature-switch-dark-theme.png
12.75 KB, image/png
Details
theme_test.png
17.37 KB, image/png
Details
theme_icons-test.zip
282.15 KB, application/x-zip-compressed
Details
virtualbox_ubuntu.png
199.79 KB, image/png
Details
Attached image See text —

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:81.0) Gecko/20100101 Firefox/81.0

Steps to reproduce:

  1. Enabled "Light" theme (one of the three that comes with TB, not the default light theme) (see image second part)
  2. Installed Signature Switch extension (http://mozext.achimonline.de/)
  3. Added Signature Switch, using Customize toolbar, in the main window or in the compose window.

OS: Windows 10 64bits; Thunderbird: 78.3.2 (32bits)

Actual results:

See first part of the image. Seems that has been selected from manifest the icon for the dark theme. That is, the "Light" theme is not recognized as a light theme. If I switch to the "Default" theme, the icon is correctly in black.

More details here: https://github.com/4ch1m/mozext/issues/5

Expected results:

The extension should detect that the theme is one of the light themes and use the correct icon.

We don't track add-on issues in bugzilla. This is something the add-on author would have to address.

Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Resolution: --- → INVALID

Sorry I dissent.
It is not a problem of the extension. If you read the "Actual result", you see that the problem is with a theme distributed with Thunderbird. That manifest itself as not "light".

If everything else is as it should, only the add-on part affected, then it still sounds like there is something the add-on needs to hook into to notice the change, which it doesn't.

Magnus,
thanks for your reply; but your statement isn't quite correct.
We're talking about the basic icon resources defined in the manifest-file of an add-on (not a custom/dedicated add-on ui).
There's nothing the add-on should implement or hook into to make this work; it should be handled by Thunderbird itself.

I already pinpointed the exact problem here:
https://github.com/4ch1m/sandbox/tree/master/theme_icons-test

It shows a very minimalistic web-/mail-extension demo; which simply adds two buttons (main window / compose window).
You can clearly see, that the (Firefox-)codebase is handling everything correct in the main window (= browser action).
But the compose window (= compose action) seems to handle things differently... and IMHO incorrectly.

Would be great if this could be addressed soon.

Thanks!

Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---

TCW, does this reproduce with beta?

Flags: needinfo?(thee.chicago.wolf)

(In reply to Wayne Mery (:wsmwk) from comment #5)

TCW, does this reproduce with beta?

You want me to install this add-on as well when testing?

Flags: needinfo?(thee.chicago.wolf)

(In reply to Arthur K. [He/Him/His] from comment #6)

You want me to install this add-on as well when testing?

I guess so. But I think we also need John to look into this.

Flags: needinfo?(john)
See Also: → https://github.com/4ch1m/mozext/issues/5

(In reply to Wayne Mery (:wsmwk) from comment #7)

(In reply to Arthur K. [He/Him/His] from comment #6)

You want me to install this add-on as well when testing?

I guess so. But I think we also need John to look into this.

Well, with Signature Switch added, it's switching to dark theme just fine on 84.0b2. I also tested with Portable TB 78.5.0 and it appears the same there as well. Maybe the OP has something in their userChrome.css like https://bugzilla.mozilla.org/show_bug.cgi?id=1665866#c6 that's causing bustage?

Hi there,

Firstly... this bug is NOT specifically related to Signature Switch.
It's a general bug on how Thunderbird is handling theme-icons defined in the manifest.

Secondly... I provided a super-simple minimalistic add-on which helps to reproduce this issue.
Please check: https://github.com/4ch1m/sandbox/tree/master/theme_icons-test
You can see that this add-on provides a light/white icon for both the "browse action"- window AND the "compose action"-window.
It also provides a dark/black icon for both the "browse action"-window AND the "compose action"-window.
(Simply checkout the add-on code and load it as a "temporary add-on".)
You will see that the icon gets correctly changed in the "browse action"-window (the main window) when changing the theme.
However, the "compose action"-window does NOT change the icon.
It should behave just exactly like the icon in the "browse action" (main window).

Thirdly... no, this is NOT something the add-on should handle. :-)

FYI ... I just tested this with a fresh install of TB 84.0b2.
The bug is still present.

Thanks!

@Achim Seufert: Your theme_icons_test worked fine for me on TB78.5 and Daily 85.0a1 (2020-11-29) (64-bit): Icons for browser_action and compose_action are always identical (blue, white, black)

Do you see errors on the console when switching themes?

Flags: needinfo?(john)

(In reply to Achim Seufert from comment #9)

Hi there,

Firstly... this bug is NOT specifically related to Signature Switch.
It's a general bug on how Thunderbird is handling theme-icons defined in the manifest.

Secondly... I provided a super-simple minimalistic add-on which helps to reproduce this issue.
Please check: https://github.com/4ch1m/sandbox/tree/master/theme_icons-test
You can see that this add-on provides a light/white icon for both the "browse action"- window AND the "compose action"-window.
It also provides a dark/black icon for both the "browse action"-window AND the "compose action"-window.
(Simply checkout the add-on code and load it as a "temporary add-on".)
You will see that the icon gets correctly changed in the "browse action"-window (the main window) when changing the theme.
However, the "compose action"-window does NOT change the icon.
It should behave just exactly like the icon in the "browse action" (main window).

Thirdly... no, this is NOT something the add-on should handle. :-)

FYI ... I just tested this with a fresh install of TB 84.0b2.
The bug is still present.

Thanks!

And you're absolutely sure you've not got a userChrome.css file lingering around somewhere in your TB "...\chrome" profile? One should not be there by default. With TB closed, could you please check for one in C:\Users\<yourwindowsusername>\AppData\Roaming\Thunderbird\Profiles\<somealphanumricstring>.default\chrome ? If a userChrome.css exists, please remove it temporarily from the folder and launch TB. Again, there ought not be a "...\chrome" folder or userChrome.css by default

Flags: needinfo?(mvalle)
Attached image theme_test.png —

OK... I've done several further tests now.

The gist: It's OS-dependant!

@Arthur: To answer your question...

And you're absolutely sure you've not got a userChrome.css file lingering around somewhere...

Yes. Definitely. I downloaded a release-tar from https://archive.mozilla.org/pub/thunderbird/releases/ and started with a fresh profile.

Since John mentioned above that everything works as expected for him, I fired up my Windows laptop and installed the test-addon.
And indeed... everything is showing up correctly.

However, on my Linux machines (Linux Mint, Ubuntu) the wrong icon is being shown.

I've created a chart (see attachment) which shows that the icon for the compose-window when using the default theme is not correct on Linux.
Everything else is correct (also if you explicitly choose a dark-/light-theme).
So... my initial description of this issue is not correct.
It has nothing to do with the dark/light theme, but only the default theme.
Sorry for the confusion.

Could someone also test this for Mac?

(In reply to Achim Seufert from comment #13)

OK... I've done several further tests now.

The gist: It's OS-dependant!

@Arthur: To answer your question...

And you're absolutely sure you've not got a userChrome.css file lingering around somewhere...

Yes. Definitely. I downloaded a release-tar from https://archive.mozilla.org/pub/thunderbird/releases/ and started with a fresh profile.

Since John mentioned above that everything works as expected for him, I fired up my Windows laptop and installed the test-addon.
And indeed... everything is showing up correctly.

However, on my Linux machines (Linux Mint, Ubuntu) the wrong icon is being shown.

I've created a chart (see attachment) which shows that the icon for the compose-window when using the default theme is not correct on Linux.
Everything else is correct (also if you explicitly choose a dark-/light-theme).
So... my initial description of this issue is not correct.
It has nothing to do with the dark/light theme, but only the default theme.
Sorry for the confusion.

Could someone also test this for Mac?

Thanks for the clarification and further testing. I'll punt this over to the Linux / Mac testers.

@Arthur: Feedback from your testers about errors reported in the console would be very helpful for debugging this.

Attached file theme_icons-test.zip —

I just tested this version (direct install) in ubuntu and there it worked as well as expected.

Attached image virtualbox_ubuntu.png —

Again... I did an elaborate test for this with a fresh Ubuntu installation.

The test-icon in the composer-toolbar is WHITE (but should be BLUE!)

Confirmed with a fresh Ubuntu 20.10.

Assignee: nobody → john
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true

I also observe inconsistency in the light theme, which is full of the dark thee artefacts, which also influence the addons. Eg, select light theme:

  1. Click on the button pane to customise the buttons observe big bloack border color https://prnt.sc/vul5vx
  2. Click on chat, click Show Chat Status and observe black bottom pane https://prnt.sc/vul6s3
  3. Install Cardbook add-on, click on any card to edit and observe black background embeddings https://prnt.sc/vul7hc

There's no chance to change the colour behaviour manually.

Stable, 78.5.1, x64, windows10

@Achim: The reason for this is: The default theme is too dark in Ubuntu! The composeToolbar2 is so dark, that some internal calculations activate the brighttext mode, which activate the (bright) image from the dark theme. That does sound sensible to me.

Magic is happening here:
https://searchfox.org/comm-central/source/mail/base/content/toolbarIconColor.js#103-129

I will check if we can do something about this.

(In reply to John Bieling (:TbSync) from comment #21)

@Achim: The reason for this is: The default theme is too dark in Ubuntu! The composeToolbar2 is so dark, that some internal calculations activate the brighttext mode, which activate the (bright) image from the dark theme. That does sound sensible to me.

That is correct.
We cover these situations and in case the user is using a LWT theme which only styles the toolbar with a dark background but not the entire theme.
We always guarantee AAA readability and color contrast, so the fact that your icon is white is 100% correct and the desired result.

I will close this as invalid.

@knedlyk: I was not able to verify your findings on Windows 10. If you can reproduce this on a different Windows 10 system, please file a new bug and specify the theme settings of your windows 10 system itself in order to be able to reproduce this.

Status: ASSIGNED → RESOLVED
Closed: 4 years ago → 4 years ago
Resolution: --- → INVALID

John,

Thanks for your investigation/findings.
Very interesting.

However, I have to strongly disagree here.
Regardless of any calculations, the icons in the main-window and the compose-window should be the same.

Please check the manifest again:

  "browser_action": {
    "default_title": "theme-icon test",
    "default_icon": "blue.png",
    "theme_icons": [
      {
        "dark": "black.png",
        "light": "white.png",
        "size": 32
      }
    ]
  },
  "compose_action": {
    "default_title": "theme-icon test",
    "default_icon": "blue.png",
    "theme_icons": [
      {
        "dark": "black.png",
        "light": "white.png",
        "size": 32
      }
    ]
  }

The definitions for browse-action and compose-action are exactly the same.
So... either BOTH should show a blue icon, or BOTH windows should show a white icon.

A different icon-/theme-handling per window doesn't make sense and looks "broken".

Simply closing this issue wouldn't improve the situation and UX either.

Would be nice if you could open a follow-up issue to fix the handling for the main-window (if you think the handling for the compose-window is correct).

Thank you!

Achim, I'm sorry but you're completely missing the point and you're approaching this from the wrong perspective.

The window decoration and toolbar background colors are defined by the Operating System, not Thunderbird.
In order to guarantee AAA readability between background and foreground elements, we calculate the contrast of the background color defined by the OS theme or the Thunderbird Theme.

You correctly specified your icon variations between light and dark, and Thunderbird is correctly using those variations to offer the best possible readability.
Based on your screenshot, do you think the blue icon would look good on the dark toolbar styled by Ubuntu?
Furthermore, users might be using a LWT theme that styles only the toolbars with a dark background, but leaves the entire theme as light. In those cases, using a dark blue icon wouldn't be readable at all.
Would you agree with this?

The icons are not different from window to window, they are the same but with the correct color variation to guarantee AAA readability.
It doesn't look broken, it is correct.

I asked our lead UX designer specifically about the two different icons and he said, this is intentional and will not be changed. The toolbar of the main window is white and therefore can pick the icon from the default theme. The toolbar of the composer is too dark and Thunderbird falls back to the icon for the dark theme.

Imagine the icon for the default theme being black: If that is used in the composer it will not work very well for the user.

Alessandro,
John,

that makes sense.
Thanks for your detailed explanation/clarification!

Agreed. :-)

Flags: needinfo?(mvalle)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: