Closed Bug 133467 Opened 24 years ago Closed 18 years ago

IMAP - unread mails in thread there are none

Categories

(MailNews Core :: Database, defect)

x86
Windows XP
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: sonja, Assigned: Bienvenu)

References

Details

Attachments

(1 obsolete file)

From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.9) Gecko/20020311 BuildID: 0.9.8 The mailer will tell me there are unread mails in a thread when there are none, when I close the thread and reopen it, there are copies of the mail at the root of the thread there. Reproducible: Didn't try Steps to Reproduce: 1. Sometimes the mailer (like once a week) says there are mails left to read, but there is no unread mail. I am using IMAP btw. 2. There will be one thread marked to contain new mail. But of course there is no unread mail in that thread. 3. I close the thread and re-expand it. Actual Results: It is then still marked 'green' to signal there is unread mail, yet there is none, the mail at the root of the thread is then copied several times into the thread. The original mails in the thread disappear. Closing and re-expanding the thread will cause more mails to appear - always the first mail ... when trying to delete the thread, the old mails start turning up and the thread display is all wrong, too. After deleting the complete thread the folder is marked read. Expected Results: Well when there is no more mail to read the folder and the thread should not be marked to contain new mail. Opening and closing a thread should not cause the 'root'-mail to be copied(?) into the thread ... I have had this occur several times, I could not figure out from the known bugs list wether this is a known bug though. Mozilla did not crash with this.
QA Contact: gayatri → laurel
accepting - are you reading imap mail on two different machines (e.g., at work during the day, and at home during the night)? Are you using the "unread messages only" view? I believe one problem in this area was fixed a couple weeks ago, but it didn't make it into .9.9, but is on the trunk.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Concerning your questions ... I am reading IMAP mail with two different computers both running Mozilla. I believe this might have happened between switches between the computers, I am not sure though. I am not using the unread messages only view (did not know such existed). The problem appeared with the old version I believe it was 0.9.8? On my laptop I am running debian which has a slightly older version currently. I will try to experiment with the two computers.
is this still happening with recent trunk builds?
Summary: Mailer says unread mails in thread there are none → IMAP - unread mails in thread there are none
This may be related. When I mark a message as read, Mozilla updates its view. Then, when the mailer checks for new messages, says the ones I've flagged as read are now unread. Clearly there is some sort of logical breakdown in the code, whereby the messages are not flagged as read on the server (the local IMAP cache won't write back to it, for whatever reason I'm guessing). This bad state will persist even if I try to force a write to the server's index by closing the browser. Any ideas? I'd just like to make unread/read sync to the server regularly so messages which are read aren't still "unread" on the server.
dylang, are you using a UW server? It sounds to me like you have two connections to the folder, and that's why you're losing state. Reading an imap msg that's in the cache does mark the message read on the server.
No, I'm using Cyrus IMAP. It happens wether or not I have one open Mozilla on one workstation, or two open Mozillas on two workstations. I think it's a Mozilla problem, because I've never been able to reproduce it in NS4.
This seems to be the same as bug 172815
*** Bug 172815 has been marked as a duplicate of this bug. ***
I have the same thing happening using a courier imap server. I currently have a folder that says there are 17 unread messages when there are none. I only access this account from one computer. Brian
Here's my observation of the bug and a possible explanation. Whenever I hit "fetch new mail" in Thunderbird 0.3, 0.4, and Mozilla mail, it'd show that I had unread email in a couple of folders that hadn't received email in over a year. If I clicked to them, the count would change and the unread status would clear. After experimenting a bit, I've determined that if you have deleted emails in the folders, but the folders haven't been compacted, the fact that the number of TOTAL emails (even deleted) and the number of visible emails is different causes the unread flag to be toggled. After I ran compact folder on the affected folders and clicked get email, no more erroneous data was being returned. Brian, can you try compacting your folder to see if this fixes it? If so, then it's a matter of if this is a bug in Mozilla/Thunderbird, or a bug in the Cyrus/Courier implementation of IMAP.
dylang, you are right, but that's not what this bug is about. The reporter is saying that a thread claims to have unread messages, but doesn't have any - that's a separate bug, and I believe is fixed (though I'm not sure). The problem you're describing has to do with checking folders other than the inbox for new messages. I've changed that to use the IMAP STATUS command on the folder instead of selecting the folder and downloading all the headers to see if there are new messages. Are these deleted messages "UNREAD"? We only look at the UNREAD count, not the TOTAL count. I hope that folders with deleted unread messages are relatively rare.
Well, where is the bug for it? It's most certainly not fixed, since the latest TBird milestone and latest Mozilla nightly have the bug. "I hope that folders with deleted unread messages are relatively rare." -- this would not be rare at all. The Mozilla/Tbird junkmail controls filter messages off before I ever see them, leaving me with many sub folders JAM PACKED with unread, deleted messages. It's a common case!
Ok, as I mentioned above I have a folder on an IMAP account that displays this problem as reported. A thread will always have the icon for unread messages and the folder always has an unread message count. Even after I select the folder. This is using the mozilla suite build 20031007, which I think might be straight 1.5. I also have a newsgroup that shows the same basic problem except that when I select it the unread count changes to the correct amount. Now all this is probably complicated by the fact that I've gone in and tried manually deleting .msf files and unsubscribed/resubscribed to the newsgroup. And to add on to all the above, I went and installed thunderbird 0.4. Letting it create a new profile and readding the accounts to it manually both IMAP and newsgroup. So far the new profile hasn't had any phantom unread messages appear. Brian
Blocks: 236849
Product: MailNews → Core
Brian "I don't believe I've seen this in recent versions." WFM also.
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → WORKSFORME
Product: Core → MailNews Core
No longer blocks: 236849
Attachment #9195235 - Attachment is obsolete: true

I think I might be getting this problem or at least a similar one on 102.3.0 (64-bit) on the Release channel. I hadn't noticed it before the 100.x.x releases and it's now happening fairly frequently, particularly when I've had TB open for long periods. Although it could be that I'm noticing it because I have TB open for longer periods now.

I have Unified Folders in the Folders pane and the Inbox will show a count of unread e-mails when there are no unread e-mails. Expanding Inbox to show the individual accounts shows no unread e-mails against any account. It looks like the overall count is not getting updated. The only way to resolve the count is to exit and restart TB.

It's intermittent but frequent. I haven't managed to pin down how to reproduce it.

P.S. I'm using IMAP.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: