Using may01 branch builds
Labels which were applied to imap messages when offline will not be available on
the same account when opened on another machine.
1. Open mail window, open an IMAP folder.
2. Download some messages for offline use (I used Get Selected Messages) and go
offline. Note: I used messages which had no labels.
3. Select one or more of the messages you downloaded, apply a label to the
4. Go back online, see that the messages are still labeled.
5. Exit Netscape.
6. On another machine, open a profile having that same IMAP account, go to that
folder and open it. Check the messages you applied labels to when you were
offline on the other machine. Notice the message labels aren't present.
Actual results: message labels applied when offline were not available on
server, not available on same IMAP account on another machine.
Expected results: message labels stored and available on other machine for same
Hmmm... should it store the label once I sync the folder? Am trying that...
attaching an imap protocol log from both machines (the one you set labels
offline and synchronize your offline changes with, and the one that you open the
folder in and expect to see the labels) would be helpful, thx!
Created attachment 81976 [details]
imap log w/labels on 2 mesgs
This log is with commercial branch 200204306 on NT 4.0
I downloaded 2 mesgs and gave them green 'personal' label.
2 mesgs had subject lines of 'wonder' and number '2'.
Created attachment 81977 [details]
log on 2nd computer w/no labels using same imap mail acnt
This log is using same imap mail acnt on commercial branch
2002050113 on linux 2.2. No labels present when I logged in.
I hope these 2 logs helped.
And regarding comment #1 -- sync/download folder didn't help any.
So another scenario (which I assume would be the same root cause, please tell me
if it needs a separate bug) is:
1. Select some IMAP messages, download for offline use.
2. Go offline.
3. Select one of the messages, label it.
4. Move it to another folder on the same IMAP server.
5. Go online.
Result: the message isn't labeled.
My understanding is that labels are only stored locally (the IMAP server is not
used to store label information), which would make it difficult or impossible
for another system to be aware of the label.
I was trying to find out whether this feature was already being considered, and
found this bug. Judging from the dates and the last comment, this seems to have
been put aside... Still, it would be a very useful feature. MS Outlook's message
flags (which are more or less equivalent to Mozilla's labels) can be set from a
machine, over IMAP, and then seen from a different machine. Looking at the
Internet headers of a message flagged for example as "For Your Information", I
see it contains the following line (just before the MIME-Version line):
X-Message-Flag: For Your Information
Couldn't this mechanism be used to store information about Mozilla's labels on
the IMAP server, as well? Or maybe this only works in Outlook because the IMAP
server I use is an MS Exchange one? Testing IMAP connectivity with telnet
<server> 143, I get:
* OK Microsoft Exchange IMAP4rev1 server version 5.5.2653.23 (mailhost) ready
Telmo, we do store labels on the server, if the server supports it. This bug is
about setting labels while offline, and not having that played back when you go
Thanks. I didn't realise that "going offline / back online" was the key aspect
of this bug. Also, sorry for the duplicate comment (don't know how to delete
it). Well, then my mail server doesn't store labels :-( By the way, in this
case, it would be useful if, when you apply a label, Mozilla showed a message
box saying "Your IMAP server doesn't allow to store labels" (with a "Don't show
this dialog again" check-box). That way, people wouldn't think it's a bug worth
Still a problem on linux/trunk. [moving component, updating summary]
*** Bug 381324 has been marked as a duplicate of this bug. ***
(In reply to comment #6)
> My understanding is that labels are only stored locally (the IMAP server is not
> used to store label information), which would make it difficult or impossible
> for another system to be aware of the label.
It most certainly is for my IMAP server, and the labels are stored and accessible on multiple machines if done so online.
However, tags applied offline are not currently reliable.
confirm for gmail imap, vista, Shredder version 3.0a2 (2008072418) and tb 184.108.40.206 same (different profiles/app ver -same imap acc)
When tagging online those stick between sessions/profiles, when tagging offline they do not stick, but for the original profile/app that tagged them.
Is this for the default first five tags ($label1-5) or for tags after the first five, or both?
I'll look into this, but I did write code to do offline playback of tag changes.
I just used default 1-5. (Thinkin that custom may go to other issues ..)
1.I just tested another trick:
-Got some tags (2,3) offline, got online. Close.
-Start other profile, no tags present on msg. Tag it (5) online.
-Start first profile again.. tadaa tag 2-3 lost, 5 is here
Idea is when tag in offline, they stick in the original app/profile as long as no other change from outside, but seams that when an online change is done, the offline tags go even in the original one.
2.If in same profile:
-has tag 5 online(from another machine/profile or just from here)
-add tag 4 offline
-go online, 4 flush, only 5 is there.
So, my conclusion would be that offline tags only work locally if no online ones present [in the same msg] from same machine or another.
Hope i don't miss a sett or a step somewhere.
[still switchin 220.127.116.11 vs 3.0a2pre to play ..]
Does this bug (offline tags not played back) happen with just a single client/machine?
I tested on a single machine, vista, tb2 and 3, switching test profiles. Or even from same profile (last point 2. in comment 16) Repro always.
Again, hope not missing something ..
fwiw, and may not worth,
I tested with another imap server. [myx.net (vodafone, former xnet)] same tb version 3.0a2 (2008072418), 2 profiles, label 1-5 ..:
The symptom of this bug is here (even if server fault ..)
-each profile show it's own "online" tags, none the offline applied
What strikes me is that even not storing labels on server (comment #9 and obvious here) still flushes offline ones on going online, not online ones, so not all of them. In same profile, same session, just goin online.
How is online status affecting this not stored on server?
on imap the first source lines for a tagged msg
From - Fri Aug 22 17:17:57 2008
(and yes, the unread status is retained on server correctly ..no -Mozilla-Keys: there)
Created attachment 335569 [details] [diff] [review]
The old code was just wrong - we need to set the right op flags on the offline operations, and then playback works fine.
(In reply to comment #20)
> fwiw, and may not worth,
> I tested with another imap server. [myx.net (vodafone, former xnet)] same tb
> version 3.0a2 (2008072418), 2 profiles, label 1-5 ..:
> The symptom of this bug is here (even if server fault ..)
> -each profile show it's own "online" tags, none the offline applied
> What strikes me is that even not storing labels on server (comment #9 and
> obvious here) still flushes offline ones on going online, not online ones, so
> not all of them. In same profile, same session, just goin online.
> How is online status affecting this not stored on server?
> on imap the first source lines for a tagged msg
> From - Fri Aug 22 17:17:57 2008
> X-Mozilla-Status: 0001
> X-Mozilla-Status2: 00000000
> Return-Path: ...
> (and yes, the unread status is retained on server correctly ..no -Mozilla-Keys:
we don't store tags in the message for IMAP, since IMAP has keywords and you can't edit an imap message anyway...
fixed, changeset 200:69676cb419aa
Comment on attachment 335569 [details] [diff] [review]
might be worth taking on the branch, after some trunk baking.
Comment on attachment 335569 [details] [diff] [review]
Approved for 18.104.22.168, a=dveditz for release-drivers
Created attachment 343925 [details] [diff] [review]
patch for branch
this is what I'll land for 1.8.1 branch.
fixed on 1.8.1 branch
Verified fixed in 22.214.171.124 with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:126.96.36.199pre) Gecko/2008110403 Thunderbird/188.8.131.52pre.