1745702 - Tags not visible in Blogs & News Feeds (RSS) view

Status: VERIFIED DUPLICATE of bug 1747909

(Thunderbird :: Mail Window Front End, defect)

Description

[peterhull90]

Attachment: Screenshot 2021-12-13 093849.png

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

Steps to reproduce:

Subscribed to an RSS feed, looked at a post in the Message Pane which had Tags

Actual results:

Tag text was not visible (just showed empty boxes)

Expected results:

See the tag text (looking at the message source, it should be "Special", "HL7 Meetings")

Comment 1

[peterhull90]

Attachment: message source

Comment 2

[peterhull90]

The feed URL is http://www.hl7.org/rss/Events.rss.cfm
I am using Windows 11 Pro 21H2

Comment 3

[peterhull90]

Further info - looking at the HTML in the devtools inspector I can see for the tags:

<mail-tagfield xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul" id="expandedtagsBox" aria-labelledby="expandedtagsLabel" class="headerValue">
  <label value="Special" class="tagvalue" style="color: white; background-color: ;" aria-label="Tags: Special"/>
  <label value="HL7 Meetings" class="tagvalue" style="color: white; background-color: ;" aria-label="Tags: HL7 Meetings"/>
</mail-tagfield>

The explicit "style" attribute with value "background-color: ;" does not look right to me, I believe that is not valid CSS.

Comment 4

[peterhull90]

OK, after some more digging I think I have found the cause. I had "Automatically create tags from feed <category> names" checked.

The label is set up in mailWidgets.js

    let color = MailServices.tags.getColorForKey(tagsArray[i]);
    let textColor = "black";
    if (!LazyModules.TagUtils.isColorContrastEnough(color)) {
      textColor = "white";
    }


    // now create a label for the tag name, and set the color
    const label = document.createXULElement("label");
    label.setAttribute("value", tagName);
    label.className = "tagvalue";
    label.setAttribute(
      "style",
      "color: " + textColor + "; background-color: " + color + ";"
    );

Since we observe "background-color: ;" it looks like color is something that stringifies to ""

Implementation for MailServices.tags.getColorForKey is (I think?) nsMsgTagService.cpp

NS_IMETHODIMP nsMsgTagService::GetColorForKey(const nsACString& key,
                                          nsACString& _retval) {
  nsAutoCString prefName(key);
  if (!gMigratingKeys) ToLowerCase(prefName);
  prefName.AppendLiteral(TAG_PREF_SUFFIX_COLOR);
  nsCString color;
  nsresult rv = m_tagPrefBranch->GetCharPref(prefName.get(), color);
  if (NS_SUCCEEDED(rv)) _retval = color;
  return NS_OK;
}

Here we see that even if m_tagPrefBranch->GetCharPref fails, nsMsgTagService::GetColorForKey still returns NS_OK, presumably returning an empty string to the caller?

So I think it would solve the problem to EITHER

• check for color being "" and set it to some other default OR
• check for color being "" and if so, don't write the explicit style to the label tag. In this case the CSS will dictate the color scheme.

The CSS would come from (possibly!) messageHeader.css though themes might override this.

The reason why color is "" is because when "Automatically create tags" is ON, the tag is created but with no color assigned to it. An example from my prefs.js:
user_pref("mailnews.tags.announcement.ordinal", "~AUTOTAG");
user_pref("mailnews.tags.announcement.tag", "Announcement");
user_pref("mailnews.tags.e-learning.ordinal", "~AUTOTAG");
user_pref("mailnews.tags.e-learning.tag", "E-Learning");
user_pref("mailnews.tags.hl7_meetings.ordinal", "~AUTOTAG");
user_pref("mailnews.tags.hl7_meetings.tag", "HL7 Meetings");
user_pref("mailnews.tags.special.color", "#408080");
user_pref("mailnews.tags.special.ordinal", "~AUTOTAG");
user_pref("mailnews.tags.special.tag", "Special");

The prefs don't have a mailnews.tags.*.color initially - I set one myself in the GUI for the "Special" tag and it showed up as mailnews.tags.special.color

Comment 6

[Wayne Mery (:wsmwk)]

Peter, can you confirm this is gone in Thunderbird 91.5.0?

Comment 7

[peterhull90]

Wayne, this appears to be be fixed in 91.7.0 - thanks very much.

Comment 8

[Wayne Mery (:wsmwk)]

Thanks for the excellent bug report.