JS error by message tags, if using a Thunderbird locale in combination with a profile created with an other locale

RESOLVED FIXED in Thunderbird2.0

Status

Thunderbird
Mail Window Front End
RESOLVED FIXED
12 years ago
12 years ago

People

(Reporter: AlexIhrig, Assigned: Scott MacGregor)

Tracking

({fixed1.8.1})

Thunderbird2.0
x86
Windows XP
fixed1.8.1

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

12 years ago
There is an JS error, when selecting a message. Tags are not shown/listed in the message header:

Error: [Exception... "Component returned failure code: 0x80004005
(NS_ERROR_FAILURE) [nsIMsgTagService.getKeyForTag]"  nsresult: "0x80004005
(NS_ERROR_FAILURE)"  location: "JS frame ::
chrome://messenger/content/mailWidgets.xml :: buildTags :: line 993"  data: no]
Source File: chrome://messenger/content/mailWidgets.xml
Line: 993

The problem could be related to the different Thunderbird locales. My
profile was created using a german Thunderbird, so the standard labels (now
tags) have german names. Now I'm running todays en-US Thunderbird with my
german profile. So the defined tags in prefs.js may have german pref-names and
differ from what the en-US Thunderbird wants to use?

Creating a new en-US profile seems to work properly. So there must be a problem
with the german standard tags - maybe a problem in encoding?

Here the lines out of my prefs.js:
-----
user_pref("mailnews.tags.$label1.color", "#FF0000");
user_pref("mailnews.tags.$label1.tag", "Wichtig");
user_pref("mailnews.tags.$label2.color", "#FF9900");
user_pref("mailnews.tags.$label2.tag", "Dienstlich");
user_pref("mailnews.tags.$label3.color", "#009900");
user_pref("mailnews.tags.$label3.tag", "Persönlich");
user_pref("mailnews.tags.$label4.color", "#3333FF");
user_pref("mailnews.tags.$label4.tag", "Zu erledigen");
user_pref("mailnews.tags.$label5.color", "#993399");
user_pref("mailnews.tags.$label5.tag", "Später");
user_pref("mailnews.tags.Gelb.color", "#FFFF00");
user_pref("mailnews.tags.Gelb.tag", "Gelb");
user_pref("mailnews.tags.Umlaut_Test_mit_&AOQA,AD8-_und_&IKw-_Euro.color", "");
user_pref("mailnews.tags.Umlaut_Test_mit_&AOQA,AD8-_und_&IKw-_Euro.tag",
"Umlaut Test mit äüü und € Euro");
user_pref("mailnews.tags.version", 1);
-----

The standard tags are UTF-8 encoded, the individual created tags ("Gelb" and
"Umlaut Test mit ......" have an other encoding. Could the UTF-8 encoding be
the problem?

Thinking about this, the encoding can't be the problem. ALL standard tags have
the JS error (independed from using encoded letters or not - e.g. "Dienstlich"
and "Sp�ter"). Only the individual created tags (both with and without encoded
letters) are working properly in the en-US Thunderbird.

Yes, there must be a problem with the 2 locales:

After tagging a message , the "Tags" column shows both words (the german AND the english). E.g.: "Sp�terLater" or "WichtigImportant" until I switch to an other folder. After switching back to the previous folder the "Tags" column only shows the english tags.
(Reporter)

Comment 1

12 years ago
BTW: using the german profile with german Thunderbird works fine.
(Assignee)

Comment 2

12 years ago
Created attachment 227634 [details] [diff] [review]
possible fix

I think this should fix it. Can you try this patch out Alexander? 

This patch passes keys around so we never have to ask the tag service for a key for a specific tag name.
(Reporter)

Comment 3

12 years ago
Your patch is working, but:

1) as a regression new applied tags are shown twice again (the code lines fixing this are removed in your patch).

2) select a message with tags -> header shows the tags; than switch to message without tags -> header still shows "Tags:" without any listed tag - the tags line isn't removed.
(Reporter)

Comment 4

12 years ago
Regression 2) is not for all messages. Maybe these are messages with tags applied and removed in the past. Or theses messages have some other garbage in DB from testing tags.
(Assignee)

Comment 5

12 years ago
regression #2 is happening because the keyword string contains keywords for things that aren't tags like Junk and NonJunk. So the front end, thinks we have tags for the message. But later when the header widget constructs its content, it can't get a tag name for Junk or NonJunk so the header is blank.
(Assignee)

Comment 6

12 years ago
Created attachment 227706 [details] [diff] [review]
better fix

Alexander, can you try this patch if you aren't too busy celebrating todays world cup victory for Germany? 

After we get the keyword string, we tokenize it and check each key for an actual tag name with the tag service, we rebuild the keyword string, filtering out the keys that don't have tag names. 

I tried some new reg expression foo to fix the other regression too.

This fixed both of the regressions you found (at least for me!)
Attachment #227634 - Attachment is obsolete: true
(Assignee)

Updated

12 years ago
Attachment #227706 - Flags: superreview?(bienvenu)

Updated

12 years ago
Attachment #227706 - Flags: superreview?(bienvenu) → superreview+
(Reporter)

Comment 7

12 years ago
The good thing first: no more JS errors and the regressions are fixed

IMAP:
If messages are tagged with the same locales of Thunderbird and the profile, tags are shown in header pane and tags column without problems in every combination of Thunderbird-locale and profile-locale. But they are everytimes shown in profiles locale - I think this is okay.

But if messages are tagged with an en-US Thunderbird in combination with a german profile (or the way round), tags are shown in the first moment in profiles locale. Deselect and reselect the tagged message shows only in tags column the tags (in Thunderbirds locale - no more in profiles locale as before). In header pane nothing is shown. This problem than occurs in every Thunderbird/profile locale combination.

POP/local accounts:
Tags are allways shown in profiles locale independet from Thunderbirds locale. No problems by different Thunderbird locales.

Hopefully I've nothing mixed up. Testing this is really confusing...
(Assignee)

Comment 8

12 years ago
I'm going to check in the patch from 06/30 for this because it does make this problem much better.

Will continue to try to figure out the last problem Alexander talked about in comment 7.
(Assignee)

Comment 9

12 years ago
fixed on the branch and trunk.
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Keywords: fixed1.8.1
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird2.0
You need to log in before you can comment on or make changes to this bug.