389937 - [SM2] No new mail notification for POP3

Status: RESOLVED DUPLICATE of bug 458625

(MailNews Core :: Backend, defect)

Description

[Sven Grull]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9a7pre) Gecko/2007072800 SeaMonkey/2.0a1pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9a7pre) Gecko/2007072800 SeaMonkey/2.0a1pre

I just switched from SM1.5 (trunk build 20070527) to SM2 (trunk build 20070728) and from this time there is no notification for new mail anymore.

The pref for checking for new mails at startup in all accounts and general pref for showing the alert for new mails are enabled.
I have several POP3 accounts set up. With SM1.5 the new mail notification still shows up.

I enabled logging for POP3 and according to the log SM identifies that there is one new message:
----------
0[3c4280]: Entering NET_ProcessPop3 68
0[3c4280]: POP3: Entering state: 3
0[3c4280]: RECV: +OK mailbox "xxxxx" has 1 messages (1227 octets) H mimap24 N
0[3c4280]: POP3: Entering state: 31
0[3c4280]: POP3: Entering state: 7
----------
But no notification windows appears nor does the tray icon.

This happens also in safe-mode with extensions disabled.

Fetching the mails via "Get messages" works without problems and afterwards the notification window (although it is transparent) and tray icon appear as usual.

Reproducible: Always

Comment 1

[Frank Wein [:mcsmurf]]

So when you start up MailNews the first time in a sessions asks you for the passwords for the mail accounts (or are the passwords saved)?

Comment 2

[Sven Grull]

In general passwords are saved. For testing purposes I removed all passwords and restarted SeaMonkey. After MailNews startup I was asked for all passwords but no new mail notification appeared afterwards. 

I just tested this with a recent Thunderbird trunk build and there happens the same - no new mail notification.

Could this be a result from the changes in bug 379070? Since the last SM1.5 trunk build there were a lot of modifications in MailNews resulting from this bug.

Comment 3

[Bruno 'Aqualon' Escherl]

Confirming using self compiled SeaMonkey/2.0a1pre debug build from 2007/07/27.

When autofetching of mails is turned off (mail.server.server<num>.download_on_biff is false), I don't get a notification window either.

I found the following difference in the console output.

With no new mails available I get:

---
Begin mail message delivery.
Abort mail message delivery.
---

When there are mails on the server, those two lines don't appear.

Comment 4

[Mark Banner (:standard8)]

Based on comment 2 I'm assuming this is a core problem. So moving to core
mailnews and cc'ing David & Scott to see if they have any ideas.

Comment 5

[Sven Grull]

This problem not only occurs at first startup of MailNews, this also happens when I already have fetched mails and leave MailNews open to check for new mails furthermore. The new mail notification does not appear after the time I have entered for the next mail check when new mail arrived in this time.

Comment 6

[Karsten Düsterloh]

How about the green arrow on the mailnews icon in SM's status bar - 
does it appear?
Does it work for IMAP?
And "tray icon" means the new mail icon in Windows' tray, right?

Comment 7

[Wayne Mery (:wsmwk)]

Sven, response to comment 6?  still see this problem?

thoughts on Bug 410419?

Comment 8

[Sven Grull]

I still see this problem. I missed to answer the questions to comment 6 in Bugzilla as there also was a thread in a German newsgroup. 

> How about the green arrow on the mailnews icon in SM's status bar - 
> does it appear?

The green arrow does not appear either.

> Does it work for IMAP?

With IMAP I don't get a biff but the message is already there when I open the IMAP inbox. So the header data seems to be downloaded immediately when connecting to the IMAP server but the biff is not triggered while doing this.

> And "tray icon" means the new mail icon in Windows' tray, right?

Yes.

Re Bug 410419 - my profile data were converted from SeaMonkey 1.5 while SeaMonkey switching to toolkit and from this time on the biff disappeared.
But the problem also occurs with a clean profile and a new entered e-mail account.

Comment 9

[Wayne Mery (:wsmwk)]

Sorry, I listed the wrong bug. See Bug 458625.  It fits the time frame of the regression and the symptoms.  If you agree, set this blocking bug 156998
and leave this open, or dupe forward to Bug 458625.

Comment 10

[Sven Grull]

Bug 458625 seems to be the same issue, duping against it.