304668 - Remotely unset IMAP labels don't propagate to local client.

Status: RESOLVED WORKSFORME

(MailNews Core :: Backend, defect)

Description

[Matthew Hodgson]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.9) Gecko/20050711 Firefox/1.0.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.9) Gecko/20050711 Firefox/1.0.5

This follows on from David Bienvenu's comment at
https://bugzilla.mozilla.org/show_bug.cgi?id=114379#c23 querying the how IMAP
message labels should behave when another client remotely unsets them. 
Currently the behaviour is to not unset them on the local client, in case legacy
labels still stored in the local database get clobbered - however, this is
useless for people who expect to see the same labelled state shared between all
clients on shared folders.  I propose a fix here which creates a
mail.imap.propagate_unlabel boolean preference for changing this behaviour for
those who want it.

Reproducible: Always

Steps to Reproduce:
1. Fire up Thunderbird on two computers, logged into the same IMAP account.
2. In client A, Label a message in one folder as red.  Watch it go red in client
B's threadpane.
3. Unlabel the message on client A.

Actual Results:  
Client B never realises that the message has been unlabeled, unless you
redownload the headers for the folder, so the message remains labelled red on
the threadpane for the rest of time, or until it's locally manually reset.

Expected Results:  
Acknowledged the update from the imapd that the message had been remotely
unlabelled, and updated the GUI view to reflect that.

Comment 1

[Matthew Hodgson]

Attachment: Allows remotely unset label behaviour to be customised according to taste.

And here's the patch.  It adds mail.imap.propagate_unlabel to allow clients to
accurately the current state of labelling on shared IMAP folders, rather than
displaying an increasingly corrupt snapshot.

Comment 2

[Adam Guthrie]

*** Bug 316312 has been marked as a duplicate of this bug. ***

Comment 3

[Scott MacGregor]

Comment on attachment 192711 [details] [diff] [review]
Allows remotely unset label behaviour to be customised according to taste.

David's the right person to review this (if we even want it). As usual I'm not to keen on adding a hidden pref for something that's set to false for most users :)

Comment 4

[David :Bienvenu]

Comment on attachment 192711 [details] [diff] [review]
Allows remotely unset label behaviour to be customised according to taste.

this patch makes every imap folder object 4 bytes bigger, which is not needed.

At this point, I don't care so much about those very old msf files (pre-thunderbird, in fact). So, I'd just as soon handle this correctly. However, we should make sure that the server supports storing labels before going and clearing the label (or does the code do that already?)

Comment 5

[David :Bienvenu]

so to be clear, I agree with Scott that adding a hidden pref for this is not needed.

Comment 6

[Oliver]

While tagging has improved in 2.0, this is still a killer for me to use it at all...

In my setup, I use two clients (both TB) for an IMAP account. The 2 clients (TB2RC1) however show a permanent discrepancy of the tag status because tag reset is obviously not propagated to the IMAP server...

Patrick Brunschwig (sitting in the office next to me) has confirmed that a fix shouldn't be too hard to do (for not to say trivial), and I couldn't find in ongoing discussions any reasons for not implementing it. Thanks to the one who actually makes it happen...

Comment 7

[David :Bienvenu]

I think on the trunk we clear the labels in this case - I'm going to mark this wfm; please re-open if you still see this problem with trunk builds.