591683 - Real-time update of Tag status changes (IMAP IDLE) does not update a second simultaneously open TB client until the mouse is moved over the email or the mail window is otherwise refreshed

Status: UNCONFIRMED

(Thunderbird :: Folder and Message Lists, defect)

Description

[bugzilla]

User-Agent:       Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648; InfoPath.1; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET4.0C)
Build Identifier: 3.1.2

With an IMAP IDLE enable setup, if an email is tagged (so that it colour code in the mailbox window), this tagging/colour coding does not get updated in a simulateously open TB client on another PC, until the mouse pointer is moved over the top of the email in question.

It is not necessary to click on the email - simply moving the mouse pointer the email is sufficient.

Reproducible: Always

Steps to Reproduce:
1. Open 2 TB clients on 2 separate PCs pointing at the same IMAP mail folder
2. Tag (colour code) the email on PC 1
3. The tagging will not be visible on PC 2 until the mouse pointer is crossed the path of the email in question at which point it will be updated immediately.  It is not necessary to click on the email - merely running the mouse pointer over the email is sufficient to trigger the GUI update.
Actual Results:  
Tag/colour coding not visible in remote TB client until mouse pointer crossed the path of the email in the mailbox contents/list window.

Expected Results:  
Tag/colour coding changes should be seen immediately on PC 2 when changed on PC 1, in the same way the toggling an email's read/unread status *is* currently updated immediately (except, that is, for Bug #590791, https://bugzilla.mozilla.org/show_bug.cgi?id=590791)

Comment 1

[Ludovic Hirlimann [:Usul]]

Both clients were started in -safe-mode right ?

Comment 2

[bugzilla]

Actually, no :-o

I would be v.surprised if the v.few and simple addons we have installed are likely to interfere or be the cause, and we haven't deviated from any "standard" config, but I understand that running in -safe-mode is a sensible thing to try if we are to be 100% sure we have eliminated every possible/potential "external" cause.

I will run for 1 week with use_condstore = false on all clients and then if that works I can switch use_condstore = true on a couple of clients and run those 2 clients in -safe-mode to see if the problem is definitely still there in -safe-mode.  Will keep you posted.

Comment 3

[bugzilla]

Sorry - pleae ignore my last comment - I posted it against the wrong bug report!  Indeed, if anyone has admin access to delete comments, please delete it (i.e. Comment 2010-08-31 05:11:23 PDT) and also this comment.

Comment 4

[bugzilla]

Yes - the problem still exists in -safe-mode.  I am fairly certain that anyone will be able to reproduce this problem 100% of the time if using Windows XP.

Comment 5

[bugzilla]

Sorry to spam my own bug report with this question, but:  How do I edit my bug reports/comments?  If poss, please would an admin give me access rights to edit my own bug reports/comments - so that I can correct any errors of my own that I spot and so make my bug reports 100% clear.  Not that I have made any major errors in my posts, but it would be a helpful facility :-)  Thanks.

Comment 6

[it]

We too are seeing this problem.
TB 3.1.20 on WinXP/7 machines
We use TB across our company and updates to Tags take on average 20-30 seconds to show up on other machines but somtimes its been reported to take a few mins.
We use Dovecot2 IMAP server, ive done some debugging with the developer and checked that with two IMAP sessions the updates are showing simultaniously on both.
This problem has only started to be reported since we migrated to TB3.

Comment 7

[it]

Seen tags though are instant between TB sessions.

Comment 8

[J.B. Nicholson]

I've seen this problem with time/date updates as well. Here's a test you can try shortly before midnight (local time):

1. Launch Thunderbird normally.
2. Mail yourself a message and make sure you receive it and have the message visible in the message list view.
3. Shortly before midnight move the mouse away from the message in the list view and wait for midnight to pass.
4. After midnight, take note of what time/date is listed for the message (probably just the time of day you sent the message).
5. Hover over the message with the mouse and see the time/date change to include the date.

I figured the entire message list view was not updated until the mouse passed over it. I would prefer the list view to be updated without regard to the mouse's positioning or anything else.