227178 - Checking folders other than inbox doesn't fire new mail notification and new mail notification fires again when an IMAP folder is opened

Status: RESOLVED FIXED

(MailNews Core :: Networking: IMAP, defect)

Description

[Ere Maijala (slow)]

Now that STATUS is used to check the new mail count it seems that the headers
downloaded when a folder (not inbox) is opened are considered new and the new
mail notification sound is played and the tray icon shown again. It could be
that it happens only if the folder wasn't in selected state already.

Comment 1

[David :Bienvenu]

I'm not able to reproduce this but I have a fix in my tree (that I just checked
in) that might also fix this. Can you try the 1.6b build that we're supposed to
put out tonight?

Comment 2

[Ere Maijala (slow)]

Is it in trunk too? At least 2003120508 shows the symptom. I'll try if I can
find out what's happening.

Comment 3

[David :Bienvenu]

I didn't check the fix in until 10AM Friday (my time), so the trunk build you
mention wouldn't have my fix. I did check it into the trunk. As far as I know,
we haven't branched yet. So if you could try a newer build and let me know, that
would be great, thx!

Comment 4

[Ere Maijala (slow)]

The problem still exists. One folder showed 5 new messages when the actual count
was 2, another showed one new, but there were none. Third one said 5, but the
actual number was 1. I have a feeling it somehow confuses the previous and later
new mail counts.

Comment 5

[David :Bienvenu]

Had you opened the folders in the current session? I'm only using the unseen
counts, + the pending unread. Do you have client-side filters that also move
messages into the folders in question?

Comment 6

[Ere Maijala (slow)]

Yes, I'm using only client-side filters. Anyway, I took a protocol log and it
seems it's the server at fault (UW-IMAPD 2001.315rh). It's reporting for example
* STATUS Mail/SPAM (MESSAGES 524 RECENT 0 UNSEEN 4 UIDNEXT 16271) although there
was only one unseen. I'll close this bug. Sorry for the disturbance.

Comment 7

[David :Bienvenu]

actually, this bug is real, even if your server is behaving oddly. Re-opening,
with a patch upcoming. Changing subject to incorporate the other problem - that
the STATUS command doesn't cause new mail notification to fire.

Comment 8

[David :Bienvenu]

Attachment: proposed fix

clearing the performingbiff flag on the folder when status is done makes it so
we don't fire the new mail notification again when you open the folder. Setting
the num new messages and biff state on the folder makes the new mail
notification fire. I'm still looking into some weirdness so there might be a
new patch upcoming.

Comment 9

[David :Bienvenu]

Comment on attachment 137659 [details] [diff] [review]
proposed fix

OK, this patch seems to be working. The weirdness I saw earlier was because of
some js changes I'd made and then undone, but w/o rebuilding chrome.

Comment 10

[Scott MacGregor]

i put this on the m4 branch David.

Comment 11

[David :Bienvenu]

fixed on trunk. I think this will be a highly visible problem in 1.6 final so
nominating for blocking. We're going to try to get some testing with new
thunderbird builds, and trunk builds.

Comment 12

[David :Bienvenu]

fixed on 1.6 branch as well.

Comment 13

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

clearing blocking1.6 nomination since this was fixed on the 1.6 branch