Open Bug 355205 Opened 19 years ago Updated 6 months ago

tags don't stay removed in the thread pane and Tag drop-down button on IMAP folders

Categories

(Thunderbird :: Mail Window Front End, defect)

Product:
Thunderbird
Component:
Mail Window Front End
Platform:
x86
Linux
Type:
defect

Tracking

(Not tracked)

Status:
REOPENED

People

(Reporter: myk, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: fixed1.8.1, triaged)

Attachments

(1 file)

proposed fix
1.39 KB, patch
mscott
: superreview+
Details | Diff | Splinter Review
After upgrading to the latest 2.0 nightly from 1.5, I'm unable to permanently remove tags from tagged emails. Pressing "0" appears to remove the tag, but if I go to another folder and then return to the one containing the tagged message, the message appears tagged again in the thread pane and the Tag drop-down button on the toolbar. Strangely, the message preview pane doesn't show the "Tags" header, so the removal appears to have some effect. Occasionally an attempt to remove a tag will succeed, although it's unclear exactly when and why. I see the problem both on tags I added before upgrading and those I added after upgrading. I see it with all three configured IMAP accounts (each one on a different server), but I don't see it with my "Local Folders" account.
Myk, are you using the new mozilla.com IMAP server?
I'm not seeing us even trying to remove the keywords from the messages on the imap server at all anymore...investigating.
Assignee: mscott → bienvenu
> Myk, are you using the new mozilla.com IMAP server? I am using that server, and I see the problem there, but I also see this on the old everyone.net IMAP server and the IMAP server at my personal mail provider (pair.com).
Attached patch proposed fix — — Splinter Review
removeallkeywords was never removing keywords from the server...
Attachment #241111 - Flags: superreview?(mscott)
> I am using that server, and I see the problem there, but I also see this on > the old everyone.net IMAP server and the IMAP server at my personal mail > provider (pair.com). Correction: I now no longer see this on the old everyone.net server, although I do still see this on the new mozilla.com server and the pair.com server. Perhaps updating to the latest nightly (and restarting to apply the update) prompted this change, or maybe I was mistaken in reporting that the problem occurred with everyone.net. In any case, I can't reproduce on that server now, but I can reproduce on the other two.
yeah, I wouldn't expect this to be a problem on everyone.net because it doesn't store keywords so it wouldn't matter that we weren't removing keywords from the server in the remove all keywords command case.
Status: NEW → ASSIGNED
Attachment #241111 - Flags: superreview?(mscott) → superreview+
fixed on trunk and branch.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Keywords: fixed1.8.1
Resolution: --- → FIXED
I'm still seeing this problem with today's build (version 2 beta 1 (20061006)). After further investigation, it appears that I can make the tag go away by first pressing 4 (to toggle the tag off) and then pressing 0 (to remove all tags). Pressing either key by itself doesn't have the desired effect.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(In reply to comment #8) > I'm still seeing this problem [...] > After further investigation, it appears that I can make the tag go away by > first pressing 4 (to toggle the tag off) and then pressing 0 (to remove all > tags). Pressing either key by itself doesn't have the desired effect. Bug 348752?
In tests using the nightly build from 2006-12-01, pressing "0" by itself has started working, but pressing "4" to remove the added tag still doesn't work.
(In reply to comment #10) > In tests using the nightly build from 2006-12-01, pressing "0" by itself has > started working, but pressing "4" to remove the added tag still doesn't work. Hmm, but pressing "0" by itself still works inconsistently, I'm finding. (In reply to comment #9) > Bug 348752? Yes, it sounds like the two are duplicates. Not sure which should be duped against the other. That bug is older, but this bug has had a patch applied.
I'm using version 2 beta 2 (20070116) on Linux and I was able to remove tags by using the 4 0 method. I was not able to remove the tags via the tags menu.
Bug 368210 looks like a duplicate, also see this bug reported against OpenSolaris: http://bugs.opensolaris.org/view_bug.do?bug_id=6527656 I am experiencing the same problem. I have messages with tags that I cannot remove at all, trying all combinations of keys 0-5 and tags menu operations. I can often add new tags and remove them, but there's usually a sticky one that won't go away, which seems to be the first one I add. I'm using IMAP with GMail. Contact me if you need more details.
I'm currently running Thunderbird 2.0.0.15pre (20080424) and in the last few builds I've noticed that I cannot remove the "Important" tag from IMAP messages hosted by GMail (I have a gmail hosted domain). Anyone else have this problem? 1. Right-click on a message 2. Tag > Important (message turns red and the Important tag shows up) 3. Right-click on the message again 4. Tag > Important Expected: the tag is removed Actual: the tag is still present (it may disappear from the message detail but if you select another message and come back to this message it says it's important again). What does work is selecting any other tag (Personal, Work, etc) and removing that... those go on and and off correctly, just the important tag cannot be removed. I also tried "Remove All Tags" and that doesn't fix it either. I tried to right-click on the folder and selected "rebuild index" and that still didn't remove the tag. So is this a google problem, or is Thunderbird not removing the appropriate header for the important tag (perhaps GMail rewrites a different header field when Thunderbird sets the important tag in the standard X-Mozilla-Keys field???)....
I am running Thunderbird 2.0.0.14 (20080421) and just found that I am unable to remove the "Important" tag from IMAP messages hosted by GMAIL. Exactly as in the description from comment #14
Same here with version 2.0.0.18 But the bug is more likely caused by Gmail and their IMAP support as I never encountered this bug using other IMAP servers. I'll try using another client to confirm that though.
seams same there, for gmail imap, but only in label1 (important) http://groups.google.com/groups?selm=3sSdnc75nYmGlqrUnZ2dnUVZ_uSdnZ2d%40mozilla.org variations and related: bug 368210 (mentioned before), bug 440951), bug 426651 cannot repro myself as not using imap on tb2 wfm in 3.0b1, gmail imap and others
Still seeing this on 3.0RC.
I just tried this out on 3.0 RC 1 Build 3 and it appears to be working just fine. I previously had a problem with this in 2.0.x though.
Using current nightly, updated today. Still occurs. But turns out this is a duplicate of 440951, which is listed in the Gmail IMAP meta-bug.
Assignee: dbienvenu → nobody

Interestingly, now on 78.3.2 I have this particular problem again on IMAP.

(In reply to m.kleineboymann from comment #21)

Interestingly, now on 78.3.2 (64-Bit) I have this particular problem again on IMAP.

--> After some testing here is how to reproduce the behavior:

  • You tag a mail with the hotkey number you assigned, e.g. "1"
  • tag shows up
  • for un-tagging you use the respective hotkey to delete all tags, e.g. "0"
  • tag disappears until you leave that folder and reopen it. Now tags show up again.

Expected behavior:

  • tags do not show up again once removed.

Workaround:

  • remove tag by using the same hotkey you used to set it, e.g. remove tag category with hotkey "1" by pressing "1" again. Tag is removed and stays removed.
Severity: normal → S3

See also bug 1940485

TLDR: remove all the extra and custom tags from settings > tags > manage tags.

I found the reason probably. I have some RSS subscriptions which automatically added some custom tags to thunderbird.

When I press the remove all tags button on an email, it calls this URL

[Parent 33027: IMAP]: D/IMAP URL failed with code 0x80550021 (imap://...@imap.mail.me.com:993/customKeywords%3EUID%3E/INBOX%3E734%3E%3E$label1%20$label2%20$label4%20$label5%20done%20industry%20world%20tamil_nadu%20sport%20society%20shorts%20real_estate%20other_sports%20olympics%20music%20mumbai%20movies%20motorsport%20motoring%20metroplus%20metro_plus%20mangaluru%20madurai%20luxury%20litfest%20lit_for_life%20lifestyle%20life_&-_style%20kolkata%20kochi%20kerala%20karnataka%20telangana%20india%20hyderabad%20homes_and_gardens%20history_&-_culture%20health%20food%20fitness%20features%20fashion%20environment%20entertainment%20education%20the_daily_brief%20dining%20delhi%20decor%20dance%20columns%20coimbatore%20children%20chennai%20business%20books%20beyond_the_charts%20bengaluru%20authors%20art%20theatre%20travel%20weekly_updates%20technology)

URL Decoded it looks like this

imap://...@imap.mail.me.com:993/customKeywords>UID>/INBOX>734>>$label1 $label2 $label4 $label5 done industry world tamil_nadu sport society shorts real_estate other_sports olympics music mumbai movies motorsport motoring metroplus metro_plus mangaluru madurai luxury litfest lit_for_life lifestyle life_&-_style kolkata kochi kerala karnataka telangana india hyderabad homes_and_gardens history_&-_culture health food fitness features fashion environment entertainment education the_daily_brief dining delhi decor dance columns coimbatore children chennai business books beyond_the_charts bengaluru authors art theatre travel weekly_updates technology)

This URL is causing the error. After extra tag removal, the error is gone.

As you asked for IMAP logging info in bug 1683125, CC :wsmwk

Flags: needinfo?(vseerror)

Hmm, history_&-_culture causing an issue perhaps? The & would likely have to be escaped and looks like it's not.

See Also: → 1683125

I can't redo the error by adding the following to custom tags..

history culture

history & culture

history &- culture

Flags: needinfo?(vseerror)
Keywords: triaged

<category><![CDATA[Life &amp; Style]]></category> The RSS feed contained this.

To redo the error, add a custom tag, Life &amp; Style and observe the parse error for icloud emails.

(In reply to pwosj from comment #28)

<category><![CDATA[Life &amp; Style]]></category> The RSS feed contained this.

To redo the error, add a custom tag, Life &amp; Style and observe the parse error for icloud emails.

I'm seeing something like this on my icloud imap account (for testing Tb). Make a custom tag as literally Life &amp; Style. Set the tag on icloud message in inbox. See the tag get set OK with the literal string. Select Drafts folder and go back to Inbox. That tag on the message is now gone and doesn't come back.

See this imap request/response from icloud:

imap.mail.me.com:S-INBOX:SendData: 91 uid store 5149 +FLAGS (life_&-amp;_style)
imap.mail.me.com:S-INBOX:CreateNewLineFromSocket: 91 BAD Parse Error (took 0 ms)

If I make the custom tag literally Life Style, it is set ok on the server like this but with blank replace with _ and uppers to lowers:

imap.mail.me.com:S-INBOX:SendData: 101 uid store 5148 +FLAGS (life_style)
imap.mail.me.com:S-INBOX:CreateNewLineFromSocket: * 4835 FETCH (UID 5148 FLAGS (nonjunk life_style))

However, removing all tags from the message fails probably because I never deleted the original tag that failed:

imap.mail.me.com:S-INBOX:SendData: 112 uid store 5148 -FLAGS ($label1 $label2 $label3 $label4 $label5 life_&-amp;_style life_style)
imap.mail.me.com:S-INBOX:CreateNewLineFromSocket: 112 BAD Parse Error (took 0 ms)

In UI, it looks like Life Style tag is removed but when I move to Drafts and back to Inbox, the Life Style tag comes back on the message.

FYI, this all works perfectly with both of these tags (no parse errors) when server is dovecot.

Not sure if this is a TB bug or a server bug (or both)?

(In reply to m.kleineboymann from comment #22)

Comment 22 STR probably has some "bad" tags created that choke the server that tb tries to remove when 0 is pressed (remove all tags on message). If the commenter is still around, I'd be curious as to which imap server was in use when the problem occurred.

Even though there also seems to be a server problem here, I'm inclined to call this a TB bug since TB should have never recorded in message db that the tag was set when the server (icloud or whatever) responded with a parsing error. And there should be better user feedback that setting the tag failed at the server, not just in activity mgr.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: