Closed Bug 141606 Opened 22 years ago Closed 16 years ago

tags applied (IMAP) when offline not available after going online

Categories

(MailNews Core :: Backend, defect, P1)

defect

Tracking

(Not tracked)

RESOLVED FIXED
Thunderbird 3.0a3

People

(Reporter: laurel, Assigned: Bienvenu)

References

(Blocks 1 open bug)

Details

(Keywords: dataloss, verified1.8.1.18)

Attachments

(4 files)

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. 

Steps:
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
selection.
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
IMAP account.
QA Contact: gchan → laurel
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!
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'.
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

T.
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

T.
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
back online...
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
reporting.
T.
Product: Browser → Seamonkey
Still a problem on linux/trunk. [moving component, updating summary]
Assignee: bienvenu → nobody
Component: MailNews: Offline → MailNews: Backend
Product: Mozilla Application Suite → Core
QA Contact: laurel → backend
Summary: Labels applied (IMAP) when offline not available/stored for launch on other machine. → tags applied (IMAP) when offline not available after going online
Flags: blocking-thunderbird3?
Severity: normal → critical
Keywords: dataloss
(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.

Product: Core → MailNews Core
confirm for gmail imap, vista, Shredder version 3.0a2 (2008072418) and tb 2.0.0.16 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.
Assignee: nobody → bienvenu
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 2.0.0.16 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 ..
Flags: blocking-thunderbird3? → blocking-thunderbird3+
high priority
Priority: -- → P1
Flags: blocking-thunderbird3.0b1+
Target Milestone: --- → Thunderbird 3.0b1
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: there)
Attached patch proposed fixSplinter Review
The old code was just wrong - we need to set the right op flags on the offline operations, and then playback works fine.
Attachment #335569 - Flags: superreview?(neil)
Attachment #335569 - Flags: review?(bugzilla)
Status: NEW → ASSIGNED
Whiteboard: have patch, awaiting reviews
(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:
> there)
> 

we don't store tags in the message for IMAP, since IMAP has keywords and you can't edit an imap message anyway...
Attachment #335569 - Flags: review?(bugzilla) → review+
Attachment #335569 - Flags: superreview?(neil) → superreview+
fixed, changeset 200:69676cb419aa
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Comment on attachment 335569 [details] [diff] [review]
proposed fix

might be worth taking on the branch, after some trunk baking.
Attachment #335569 - Flags: approval1.8.1.18?
Attachment #335569 - Flags: approval1.8.1.18? → approval1.8.1.18+
Comment on attachment 335569 [details] [diff] [review]
proposed fix

Approved for 1.8.1.18, a=dveditz for release-drivers
Whiteboard: have patch, awaiting reviews
Attached patch patch for branchSplinter Review
this is what I'll land for 1.8.1 branch.
fixed on 1.8.1 branch
Keywords: fixed1.8.1.18
Verified fixed in 1.8.1.18 with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.18pre) Gecko/2008110403 Thunderbird/2.0.0.18pre.
You need to log in before you can comment on or make changes to this bug.