Description:
The address bar “star” button for bookmarked pages has a different color between some privileged and generated themes.
In the case of some of those generated themes this “star” button may also become very hard to see as the color almost matches the address bar background.

Affected themes:

• life-in-color—abstract-balanced-colorway
• life-in-color—cheers-balanced-colorway
• life-in-color—elemental-balanced-colorway
• life-in-color—foto-balanced-colorway
• life-in-color—graffiti-balanced-colorway
• life-in-color—lush-balanced-colorway

Steps to reproduce:

1. Prepare two instances of Nightly with new profiles
2. Access about:config on both and set extensions.experiments.enable to true
3. Restart the browsers to apply the above pref
4. Load a pair of the same generated and privileged theme in the browsers via about:debugging
5. Bookmark a page on both browsers
6. Observe the color difference of the “star” button between the privileged and generated themes
7. Observe that in the case of several generated themes the “star” button is barely visible against the address bar background

Actual:

1. Generated themes bookmarked page “star” button color is different from the ones used by the privileged theme.
2. In the case of several generated themes the “star” button is barely visible against the address bar background

Expected:

1. Generated themes bookmarked page “star” button color should be the same as the one used by the privileged theme.
2. There should be more contrast between the background color of the address bar and the bookmarked page “star” button on several generated themes so as the button is visible.

Hey Dao,
would you mind to take a look into this? I'd like to get your perspective on this particular visual regression of the non-privileged version of the theme, so that we can agree on how to proceed about it.

So with the toolbar_field_icons_attention experimental property removed, this will use icons_attention as defined by the theme. For theme where this causes problems, I'd suggest we stop setting icons_attention so that our default fallback is used (rgb(0,97,224) and rgb(0,221,255), respectively): https://searchfox.org/mozilla-central/rev/893a8f062ec6144c84403fbfb0a57234418b89cf/browser/themes/shared/toolbarbutton-icons.css#13,18

Luca, how does this sound to you?

(In reply to Dão Gottwald [::dao] from comment #2)

So with the toolbar_field_icons_attention experimental property removed, this will use icons_attention as defined by the theme. For theme where this causes problems, I'd suggest we stop setting icons_attention so that our default fallback is used (rgb(0,97,224) and rgb(0,221,255), respectively): https://searchfox.org/mozilla-central/rev/893a8f062ec6144c84403fbfb0a57234418b89cf/browser/themes/shared/toolbarbutton-icons.css#13,18

Luca, how does this sound to you?

My main concern would be that all the colorway themes have a specific color theme, and those fallback colors are very specific colors which may not be always look that great when combined with some of the colorway theme colors.

Based on a very quick look another alternative option I can think of is to set icons_attention to the same value set on frame (which is the one used as the accent color, and so the one that is used for the tabbar background).

For the themes that I tried explicitly (which are 3 of the ones in the list from comment 0) that seems to be looking pretty good for the bookmark icon, but I'm not sure if that icons_attention value would be actually used for any other UI element that may need to provide contrast with the frame color, wdyt?

The screenshot attached does show a comparison of how the rgb(0, 221, 255) color would look like when combined with life-in-color—graffiti-balanced-colorway (which is the purple one from the screenshot in comment 0) and how that looks if the icons_attention is set to the frame color.

Should we ask UX for their perspective about using the simplest option (removing icons_attention and just fallback to the current default for those icons)?

An additional option we may also want to consider is if it would be worth adding official support for toolbar_field_icons_attention through the needed changes on the Firefox side (and then tweak the script that automates generating all non-privileged xpi files to keep that color property).

wdyt?

(In reply to Luca Greco [:rpl] [:luca] [:lgreco] from comment #3)

My main concern would be that all the colorway themes have a specific color theme, and those fallback colors are very specific colors which may not be always look that great when combined with some of the colorway theme colors.

Based on a very quick look another alternative option I can think of is to set icons_attention to the same value set on frame (which is the one used as the accent color, and so the one that is used for the tabbar background).

For the themes that I tried explicitly (which are 3 of the ones in the list from comment 0) that seems to be looking pretty good for the bookmark icon, but I'm not sure if that icons_attention value would be actually used for any other UI element that may need to provide contrast with the frame color, wdyt?

The screenshot attached does show a comparison of how the rgb(0, 221, 255) color would look like when combined with life-in-color—graffiti-balanced-colorway (which is the purple one from the screenshot in comment 0) and how that looks if the icons_attention is set to the frame color.

The Downloads button uses the attention color and can be moved to the tab bar (i.e. on the frame background), so I think that wouldn't work.

Should we ask UX for their perspective about using the simplest option (removing icons_attention and just fallback to the current default for those icons)?

Not sure we have a UX contact here, I'd ask Misha but she's on PTO all of next week I believe. I guess we can pass this decision on to Ray.

An additional option we may also want to consider is if it would be worth adding official support for toolbar_field_icons_attention through the needed changes on the Firefox side (and then tweak the script that automates generating all non-privileged xpi files to keep that color property).

That color would only be used by this single button (the star button), so I tend to think that this doesn't quite pass the threshold for extending the API.

(In reply to Dão Gottwald [::dao] from comment #4)

Should we ask UX for their perspective about using the simplest option (removing icons_attention and just fallback to the current default for those icons)?

Not sure we have a UX contact here, I'd ask Misha but she's on PTO all of next week I believe. I guess we can pass this decision on to Ray.

One thing to keep in mind here is that Life in Color was our very first collection, and I suspect it has the lowest number of users at this point. So I think this is a reasonable tradeoff.

Ray, what do you think about using the default attention color for the colorways listed in comment 0? See the first part of attachment 9312243 [details] for how that would look.

Thanks for the ping! Do we have alternative options for setting the color there by chance? My worry is that the example in the screenshot creates contrast issues (the lighter blue star doesn't read well against the light url bar background).

(In reply to Ray Fambro from comment #6)

Thanks for the ping! Do we have alternative options for setting the color there by chance? My worry is that the example in the screenshot creates contrast issues (the lighter blue star doesn't read well against the light url bar background).

We have two default attention colors, but we seem to be picking the wrong one here. Let's fix that! I've filed bug 1811267.

I'm closing this bug as fixed:

• besides the changes on the Firefox side landed from Bug 1811267, this bug only needed one small tweak to the generated xpi files to apply the changes we agreed on (mentioned in comment 2).
• I've already updated the script that generates the non-privileged colorway theme xpi files to apply the fix needed on the theme property side (removing the icons_attention color) from the themes that were hitting this issue (the once listed in comment 0), and bump the theme version in all new the generated xpi files to 2.1 (on all the regenerated xpi files. not just the ones actually changed because hitting this particular visual regression).
• I've also regenerated all the xpi files and provided a link to where they have been uploaded to all parts involved into QA verification and submission of the theme XPI files to AMO.

The dependency, Bug 1811267, has been fixed and verified on the latest Nightly. Tested on Windows 10 x64 and Ubuntu 16.04 LTS with the newly available tweaked generated themes.

As a direct result, the bookmark star button is now visible at all times on the themes specified in Comment 0.

Since I verified the proper display of the bookmark button already as part of Bug 1811267, I will set this one as Verified Fixed as well.