1445543 - Tags (imap keywords) don't update (display) automatically when changed on an IMAP server account that is being accessed by multiple TB clients

Status: NEW

(MailNews Core :: Networking: IMAP, defect)

Description

[Antony K]

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:58.0) Gecko/20100101 Firefox/58.0
Build ID: 20180206200532

Steps to reproduce:

When I have multiple Thunderbird clients on different Windows PCs connecting to a shared IMAP mail account (Dovecot mail server), if I change the 'flag' on one PC/Thunderbird client ("#1"), the flag state changes within a second on the other PC/Thunderbird client ("#2") (via IDLE), but this 'instant update' behavior does not happen when changing tags. 


Actual results:

The tag(s) for a specific e-mail are only updated if I mouse over that e-mail on the  PC/Thunderbird client #2's message list pane, or if something else causes the message list to be refreshed (i.e. a new incoming e-mail).
Note: It appears that Thunderbird (client #2) 'knows' that the flag has been set, it's just not updating the message list display. I proved this by setting a tag on client #1, waiting a few seconds, pulling the LAN cable on client #2, then mousing over the tag-altered e-mail on client #2 - the tag was updated to reflect the change even though the connection to the IMAP server had been broken.


Expected results:

The tags should update in the same way that the flag does. That is, if I change the flag(s) on client #1, it should be displayed automatically on client #2 within a second or so. This behaviour was alluded to by Gene Smith comments #41 & #42 
https://bugzilla.mozilla.org/show_bug.cgi?id=583677
...but as per the guidelines it sounded like is was best to start a new thread/report.
Sorry for my newbieness.

Comment 1

[Wayne Mery (:wsmwk)]

I don't have time to investigate but yes there are some  similar bugs in https://mzl.la/2HwOhDc

Comment 3

[Jorg K (CEST = GMT+2)]

Gene, we had recent changes in the "tag area", bug 583677. Does that fix this?

Comment 4

[gene smith]

Jorg, I don't think it's the same problem. He can still see the tag on tb #2 but just has to "mouse over" or click the folder to see it change color, I think he saying. I also observed the "mouse over" effect when I was working on bug 583677 comment 42. At the time I didn't see it as a problem. In bug 583677 users that didn't have permission to create tags couldn't see tags created and set by higher privilege users.

Reporter, which folder were you setting the tag in? Was it Inbox or some other folder? My first thought would be that the problem is due to imap IDLE not being active on the folder (default 5 folders can have IDLE going). But your "pull the cable" test seems to eliminate that.

Also, reporter, which "flags" do you see that update instantly? I assume you are referring to standard flags like \seen that indicate a message has been read.? Do these work in the same folder you say tags don't work?

I will go and try to duplicate this now.

Comment 5

[gene smith]

Yes, I can duplicate the behavior with tb 60.6.1. On client #1 I can toggle the read/not-read state of a message and on client #1 I see the summary change from not-bold to bold with no user activity. But when I change a tag on client #1, it does not change color at client #2 until the mouse pointer touches the message summary, and no click on folder or message is required. The folder on client #2 is using IDLE.

I haven't looked at the code but this sounds more like a UI problem rather than imap.

Comment 6

[gene smith]

(In reply to Jorg K (GMT+2) from comment #3)

Gene, we had recent changes in the "tag area", bug 583677. Does that fix this?

I just tried with a Daily with patch for bug 583677 in place. I still don't see an update until I do the "mouse over". So the answer is no.

Comment 8

[gene smith]

Yes, imap IDLE response shows \flagged set and $label1 set after after "starring" and setting "Important" tag using another TB profile accessing the same dovecot account. The star appears on its own but the "important" tag requires clicking the message to be seen (red highlight). The click on the message doesn't cause any imap networks activity so, as I suggested in comment 5, appears to be UI problem.
I will look closer at this ASAP.