Folder unread count keeps reverting

RESOLVED FIXED in mozilla1.8alpha2

Status

MailNews Core
Networking: IMAP
--
major
RESOLVED FIXED
14 years ago
10 years ago

People

(Reporter: Iain MacDonnell, Assigned: Bienvenu)

Tracking

(Blocks: 1 bug)

Trunk
mozilla1.8alpha2
Other
Linux

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: fixed-aviary1.0)

Attachments

(3 attachments, 1 obsolete attachment)

(Reporter)

Description

14 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040524 Firefox/0.8.0+
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040524 Firefox/0.8.0+


I have IMAP accounts, each with server-side filtering of mailing lists into
folders. I have thunderbird configured to check these folders for new messages.

With recent aviary builds, I've begun seeing odd behaviour. When a folder has
new messages, I go to that folder and read them. The unread count goes to zero,
BUT, if I leave the folder (ie. choose another), on the next check for new
messages (either scheduled or when I click on the "Get Mail" button, the unread
count (in the "Folders" pane) goes back to what it was before I read the
messages. If I go back to the folder, it returns to zero.

This only seems to happen for the last folder that had unread messages - ie.
if I reproduce it for a different folder, it stops happening for the previous
one.

It doesn't happen all the time, but enough to be irritating.

This happens with at least two different accounts (same profile). One is a
SunONE Messaging Server, the other Cyrus IMAP, so I'm pretty sure it's not
a server issue.

I guess it could be a bad index cache or something, maybe as a result of some
of the recent profile changes - it definitely started happening shortly after
I start using the aviary branch.


Reproducible: Sometimes
Steps to Reproduce:
1. 
2.
3.
(Assignee)

Updated

14 years ago
Assignee: mscott → bienvenu
Status: UNCONFIRMED → NEW
Component: Mail Window Front End → Networking: IMAP
Ever confirmed: true
Product: Thunderbird → MailNews
Target Milestone: --- → mozilla1.8alpha2
Version: unspecified → Trunk
(Assignee)

Comment 1

14 years ago
a protocol log would be useful here too:

http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#imap

my guess is that this is related to a change I made so that we don't issue a
STATUS command on a selected state folder, but do a NOOP instead...an annotated
protocol log (i.e., with a comment about which folder had the wrong counts)
would be helpful. Thx!
(Reporter)

Comment 2

14 years ago
Created attachment 149944 [details]
Annotated IMAP protocol log

Attaching annotated protocol log as requested.
(Reporter)

Comment 3

14 years ago
Created attachment 149950 [details]
Another example


In this example, the folder "jabber/jabberd" was showing the wrong count. This
log starts from when message-id
783A3EE2AA17B349B869477606E922A6AE4A8D@USMAIL04.morinda.com
was new - you can see me go in and read it. When I left that folder, the unread

count returned to (1).
(Reporter)

Comment 4

14 years ago
BTW, what I previous interpretted to be this only happening to the last folder
that had received new messages may actually be that it only happened to folders
that have a "cached" (kept-alive) connection - I use up the default 5 connections
pretty quickly. This would seem to gel with your NOOP theory...
(Assignee)

Comment 5

14 years ago
My guess is that NOOP doesn't clear the recent count, so the second time its
run, it uses the previous value. Duh. So, I think the fix is to clear the
parser's fNumberOfRecentMessages before issuing the NOOP. Proposed fix upcoming.
Related to bug 239196?
(Assignee)

Comment 7

14 years ago
thx, yeah - that one should be re-closed, and I'll leave this one open. 
(Assignee)

Comment 8

14 years ago
Created attachment 149959 [details] [diff] [review]
proposed fix

Updated

14 years ago
Blocks: 36011
(Reporter)

Comment 9

14 years ago
Have applied the proposed fix and now waiting to see if the problem comes back...
(Assignee)

Updated

14 years ago
Attachment #149959 - Flags: superreview?(mscott)

Updated

14 years ago
Attachment #149959 - Flags: superreview?(mscott) → superreview+
(Reporter)

Comment 10

14 years ago
I'm afraid it looks like this patch is a little too aggressive - it appears that
those folders which have open connections now do not report unread messages on
"Get Mail" checks anymore :(
(Assignee)

Comment 11

14 years ago
I think they report the unread/recent messages on the first check, but not
subsequent checks - but I have to turn off idle support to be sure. Maybe I
should just clear the recent count on NOOPs...
(Assignee)

Comment 12

14 years ago
no, that won't work - that's all we're doing in the case where you're seeing the
problem...maybe just clear it when we actually select the folder in the ui? Argh.
(Reporter)

Comment 13

14 years ago
I suppose it depends on your interpretation if "recent". If I get a bunch of new
messages in a mailing list folder, I might go and peek to see if any are really
interesting, but may not read all of them right away. I still want the unread
count for that folder to be accurate.

The difference between "recent" and "unseen" in IMAP has always been a bit fuzzy
for me ... 
(Assignee)

Comment 14

14 years ago
this doesn't make sense - we're actually ignoring the num recent count
completely, partly because RECENT is not reliable and you can have RECENT read
or deleted messages...but it does make it silly to use NOOP, which only gives
you a RECENT count. It's probably the numunread that we're not clearing, and
that's what caused your initial bug report. But I doubt this patch actually
caused a change in behaviour - it was probably broken before. But, I think I'm
going to back out the fix that caused this problem in the first place, and think
of a better fix for the  very first problem of doing a STATUS with a selected
folder. One possibility is to just get the new headers for the folder if we had
a selected state connection to it, but we don't really know that at the point
which we need to know it at...

(Assignee)

Comment 15

14 years ago
Created attachment 150038 [details] [diff] [review]
proposed fix
Attachment #149959 - Attachment is obsolete: true
(Assignee)

Comment 16

14 years ago
I'll check this in, and re-open the old bug about not issuing STATUS for
selected state folders.

Comment 17

14 years ago
*** Bug 245589 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 18

14 years ago
Have backed out the previous proposed fix and applied the new one. All seems to be
well with the world (or at least my world) again... thanks!

Comment 19

14 years ago
Ian what version of thunderbird were you using when you filed this? A trunk or a
0.7 branch build?

Comment 20

14 years ago
2004-06-04 patch is now in the aviary 1.0 branch
Whiteboard: fixed-aviary1.0
(Assignee)

Comment 21

14 years ago
fixed by backing out fix for bug 239181
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED
(Reporter)

Comment 22

14 years ago
(In reply to comment #19)
> Ian what version of thunderbird were you using when you filed this? A trunk or a
> 0.7 branch build?

I was using my own build from AVIARY_1_0_20040515_BRANCH

(Assignee)

Comment 23

14 years ago
*** Bug 245769 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 24

14 years ago
Iain, if you get a chance, can you try this patch
http://bugzilla.mozilla.org/attachment.cgi?id=150230&action=view in
http://bugzilla.mozilla.org/show_bug.cgi?id=245769 and let me know if the folder
unread count still works, and we notice new mail? I'm thinking of checking it in
since it will prevent us from issuing STATUS on a folder that we are in the
selected state on. Thx!
(Reporter)

Comment 25

14 years ago
(In reply to comment #24)
> Iain, if you get a chance, can you try this patch

Sure! I have incorporated this in my debug build, and am running with it now.
Looks fine so-far .. will see how it behaves over the next few hours ....


(Reporter)

Comment 26

14 years ago
(In reply to comment #25)
> (In reply to comment #24)
> > Iain, if you get a chance, can you try this patch
> 
> Sure! I have incorporated this in my debug build, and am running with it now.
> Looks fine so-far .. will see how it behaves over the next few hours ....

It's been working fine since ... I have observed no anomalous behaviour.

Now I'm off to watch the Stanley Cup final ... so no more testing today :)


(Assignee)

Comment 27

14 years ago
Iain, thx for trying it out.
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.