Forwarded "icon" not shown up in IMAP account (index issue?)

VERIFIED FIXED in Thunderbird 3.1a1

Status

VERIFIED FIXED
12 years ago
9 years ago

People

(Reporter: public.lp, Assigned: Bienvenu)

Tracking

Thunderbird 3.1a1
x86
Windows XP
Bug Flags:
blocking-thunderbird3.1 +

Thunderbird Tracking Flags

(thunderbird3.0 .1-fixed)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

12 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3
Build Identifier: version 2.0.0.0 (20070326)

We are using one email account on several PCs, over Thunderbird.
If I answer an email on one PC, as soon as I will go to the folder of this email on another PC, I'll see the "replaied" green arrow on the email.
Forwarding the email won't show up the purple icon on the other PC (although the icon will show up on the PC used to forward the message).

Moving later the message to another folder, the message gets its icon. Rebuilding the index also works, but we don't really want to rebuild every 5 minutes the index on a 5000 emails forlder...

It works pretty fine with replying, maybe it could work as fine with forwarding?

Reproducible: Always

Steps to Reproduce:
1. Receive one email on your imap account, on PC1
2. Forward this email from PC1, to anywhere.
3. Check your account on PC2, not purple arrow shown.
[4. Rebuild the index of the folder on PC2, arrow now appears]
[4bis. Move the message to another folder from any PC, when opening this folder on PC2 the arrow will be visible]
Actual Results:  
After step 3, "nothing happens" when the arrow should be visible.

Expected Results:  
Purple "forwarded" arrow shown without having to rebuild index or move message to another folder.
Version: unspecified → 2.0

Comment 1

12 years ago
We have the same problem, very annoying because we work on shared PCs and with shared mailboxes
The flag forwarded for an already existant message is not updated on others PC (only local flag is OK)

We look with Ethereal, and we could see that the status is existing on the imap server but not handled by Thunderbird
(* 46 FETCH (FLAGS (\Recent \Seen $Forwarded) UID 46))

Others flags (/seen, /replied, $Label1, ... $Label5) are working good

Tests were made with Cyrus and Courrier IMAP server and we have the same problem.

Thunderbird: version 2.0.0.4 (20070604) 

Ethereal trace:
794 IDLE

+ idling

DONE

* 46 EXISTS
* 26 RECENT
794 OK Completed

795 noop

795 OK Completed

796 getquotaroot "INBOX"

* QUOTAROOT INBOX
796 OK Completed

797 UID fetch 46:* (FLAGS)

* 46 FETCH (FLAGS (\Recent) UID 46)
797 OK Completed (0.000 sec)

798 UID fetch 46 (UID RFC822.SIZE FLAGS BODY.PEEK[HEADER.FIELDS (From To Cc Subject Date Message-ID Priority X-Priority References Newsgroups In-Reply-To Content-Type)])

* 46 FETCH (FLAGS (\Recent) UID 46 RFC822.SIZE 1295 BODY[HEADER.FIELDS (From To Cc Subject Date Message-ID Priority X-Priority References Newsgroups In-Reply-To Content-Type)] {230}
Message-ID: <4695CBF0.1060603@coco.net>
Date: Thu, 12 Jul 2007 08:36:32 +0200
From: Jyves <jy@coco.net>
To:  jy@coco.net
Subject: 5555
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

)
798 OK Completed (0.000 sec)

799 UID fetch 46 (UID BODY.PEEK[HEADER.FIELDS (Content-Type Content-Transfer-Encoding)] BODY.PEEK[TEXT]<0.2048>)

* 46 FETCH (UID 46 BODY[HEADER.FIELDS (Content-Type Content-Transfer-Encoding)] {96}
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

 BODY[TEXT]<0> {4}


)
799 OK Completed (0.000 sec)

800 UID fetch 46 (UID BODY.PEEK[HEADER.FIELDS (Content-Type Content-Transfer-Encoding)] BODY.PEEK[TEXT]<0.2048>)

* 46 FETCH (UID 46 BODY[HEADER.FIELDS (Content-Type Content-Transfer-Encoding)] {96}
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

 BODY[TEXT]<0> {4}


)
800 OK Completed (0.000 sec)

801 IDLE

+ idling

DONE

801 OK Completed

802 UID fetch 46 (UID RFC822.SIZE BODY[])

* 46 FETCH (FLAGS (\Recent \Seen) UID 46 RFC822.SIZE 1295 BODY[] {1295}
Return-Path: <jy@coco.net>
Received: from murder ([unix socket])
. by valafar (Cyrus v2.2.13-Debian-2.2.13-10) with LMTPA;
. Thu, 12 Jul 2007 08:34:30 +0200
X-Sieve: CMU Sieve 2.2
Message-ID: <4695CBF0.1060603@coco.net>
Date: Thu, 12 Jul 2007 08:36:32 +0200
From: Jyves <jy@coco.net>
User-Agent: Thunderbird 2.0.0.4 (Windows/20070604)
MIME-Version: 1.0
To:  jy@coco.net
Subject: 5555
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit



)
802 OK Completed (0.000 sec)

803 uid store 46 +Flags (\Seen)

803 OK Completed

804 IDLE

+ idling

DONE

* 46 FETCH (FLAGS (\Recent \Seen $Forwarded))
804 OK Completed

805 noop

805 OK Completed

806 getquotaroot "INBOX"

* QUOTAROOT INBOX
806 OK Completed

807 UID fetch 47:* (FLAGS)

* 46 FETCH (FLAGS (\Recent \Seen $Forwarded) UID 46)
807 OK Completed (0.000 sec)

808 IDLE

+ idling

DONE

808 OK Completed

809 noop

809 OK Completed

810 getquotaroot "INBOX"

* QUOTAROOT INBOX
810 OK Completed

811 UID fetch 47:* (FLAGS)

* 46 FETCH (FLAGS (\Recent \Seen $Forwarded) UID 46)
811 OK Completed (0.000 sec)

812 IDLE

+ idling

DONE

812 OK Completed

813 noop

813 OK Completed

814 getquotaroot "INBOX"

* QUOTAROOT INBOX
814 OK Completed

815 UID fetch 47:* (FLAGS)

* 46 FETCH (FLAGS (\Recent \Seen $Forwarded) UID 46)
815 OK Completed (0.000 sec)

816 IDLE

+ idling

DONE

816 OK Completed

817 noop

817 OK Completed

818 getquotaroot "INBOX"

* QUOTAROOT INBOX
818 OK Completed

819 UID fetch 47:* (FLAGS)

* 46 FETCH (FLAGS (\Recent \Seen $Forwarded) UID 46)
819 OK Completed (0.000 sec)

820 IDLE

+ idling


Assignee: mscott → nobody
I think that the status of this bug should be "confirmed".

It is easy to test and reproduce:
1- go to your imap webmail
2- answer to one message and forward one another
3- disconect from your webmail and open Thunderbird
=> you will see that the flag for the answered message is OK, but no flag for the forwarded message...

Expected Results: both messages (answered and forwarded) should have the correct flag into Thunderbird.

I tried to rebuild the index, but it doesn't succeed to display the forwarded flag.

Test with Thunderbird 2.0.16 on Windows XP.
Reporter the issue still exists also with latest 2.0.0.23 release?
 caméléon, do you see this issue in version 3?
 http://www.mozillamessaging.com/en-US/thunderbird/early_releases/
Whiteboard: closeme 2009-12-20 [needs reporter retest]
Hi,
Yes, Im am currently using TB3 RC1 (Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.1.5) Gecko/20091121 Thunderbird/3.0) with an imap account on laposte.net (french provider) and the problem is still the same.
server issue?
Whiteboard: closeme 2009-12-20 [needs reporter retest]
Version: 2.0 → 3.0
(In reply to comment #6)
> server issue?
How can we know?
(Assignee)

Comment 8

9 years ago
Ugh, I'm seeing this too.
Assignee: nobody → bienvenu
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
(Assignee)

Comment 9

9 years ago
But it's very tricky to reproduce...I think it works if the msg has the flag when we download all the headers, so rebuild index would actually fix it. It just doesn't work if we notice the forwarded flag when just doing a flag sync.
(Assignee)

Comment 10

9 years ago
This fix should go into 3.01. I have a patch for it, but I need to somehow write a test case for this, which is going to be a bit tricky with the fake server.
Flags: blocking-thunderbird3.1+
(Assignee)

Comment 11

9 years ago
Created attachment 416261 [details] [diff] [review]
proposed fix

simple fix; I'm not sure how I'm going to do the test case, but I'll try to figure it out this weekend.
Thanks for this quick fix. I would be glad to help you if you need testers (and if it is very simple to do ;-) )
(Assignee)

Comment 13

9 years ago
Created attachment 416869 [details] [diff] [review]
proposed fix

This adds an xpcshell test to check our handling of detecting flags that are added/removed. I had to fix a bug with detecting the removal of the last tag on a message as well. I didn't test the removal of the replied flag since that doesn't happen in the real world...
Attachment #416261 - Attachment is obsolete: true
Attachment #416869 - Flags: superreview?(bugzilla)
Attachment #416869 - Flags: review?(bugzilla)
Attachment #416869 - Flags: superreview?(bugzilla)
Attachment #416869 - Flags: superreview+
Attachment #416869 - Flags: review?(bugzilla)
Attachment #416869 - Flags: review+
Attachment #416869 - Flags: approval-thunderbird3.0.1+
Checked in to trunk: http://hg.mozilla.org/comm-central/rev/d50dea7fab8f
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 3.1a1
Checked into branch: http://hg.mozilla.org/releases/comm-1.9.1/rev/821b07433e4c
status-thunderbird3.0: --- → .1-fixed
Status: RESOLVED → VERIFIED
Keywords: verified-thunderbird3.0
You need to log in before you can comment on or make changes to this bug.