Closed Bug 245044 Opened 20 years ago Closed 20 years ago

Folder unread count keeps reverting

Categories

(MailNews Core :: Networking: IMAP, defect)

Other
Linux
defect
Not set
major

Tracking

(Not tracked)

RESOLVED FIXED
mozilla1.8alpha2

People

(Reporter: mozbugs, Assigned: Bienvenu)

References

(Blocks 1 open bug)

Details

(Whiteboard: fixed-aviary1.0)

Attachments

(3 files, 1 obsolete file)

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: 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
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!
Attaching annotated protocol log as requested.
Attached file 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).
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...
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.
thx, yeah - that one should be re-closed, and I'll leave this one open. 
Attached patch proposed fix (obsolete) — Splinter Review
Blocks: biff
Have applied the proposed fix and now waiting to see if the problem comes back...
Attachment #149959 - Flags: superreview?(mscott)
Attachment #149959 - Flags: superreview?(mscott) → superreview+
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 :(
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...
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.
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 ... 
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...

Attached patch proposed fixSplinter Review
Attachment #149959 - Attachment is obsolete: true
I'll check this in, and re-open the old bug about not issuing STATUS for
selected state folders.
*** Bug 245589 has been marked as a duplicate of this bug. ***
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!
Ian what version of thunderbird were you using when you filed this? A trunk or a
0.7 branch build?
2004-06-04 patch is now in the aviary 1.0 branch
Whiteboard: fixed-aviary1.0
fixed by backing out fix for bug 239181
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
(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

*** Bug 245769 has been marked as a duplicate of this bug. ***
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!
(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 ....


(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 :)


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.

Attachment

General

Created:
Updated:
Size: