898885 - No alerts shown for Unix Movemail server accounts

Status: RESOLVED WONTFIX

(MailNews Core :: Movemail, defect)

Description

[GJ]

User Agent: Mozilla/5.0 (X11; Linux i686; rv:22.0) Gecko/20100101 Firefox/22.0 (Beta/Release)
Build ID: 20130626010747

Steps to reproduce:

Thunderbird is installed in ArchLinux with KDE 4.10

A Unix Movemail account is created.
In Menu --> Edit --> Preferences --> General --> Show an alert is checked
In Menu --> Edit --> Account Settings --> Server Settings (of the Movemail account) --> Check for new messages at startup is checked
In Menu --> Edit --> Account Settings --> Server Settings (of the Movemail account) --> Check for new messages every 1 minutes is checked
In Menu --> Edit --> Account Settings --> Server Settings (of the Movemail account) --> Automatically download new messages is checked

I send an e-mail to this Unix Movemail account


Actual results:

The new e-mail is shown in bold in the Thunderbird Inbox screen.
The "New Mail counter" is also increased


Expected results:

An alert should also have been shown.

Remark: this bug might be related to Bug 270186 (New Mail Sound does not work on movemail accounts)

Comment 1

[rsx11m]

Ah, I've missed that other bug when searching for similar issues. The sound not showing up either would suggest that both issues are related, given that handling of both alerts (though OS-specific) is done in the same function. Thus, it may be a problem in nsMessengerUnixIntegration::ShowNewAlertNotification() itself or in a (potentially OS-unspecific) function leading up to it.

It may also make a difference if libnotify is used, but given that parallel POP3 accounts work fine, it appears that the alerts aren't triggered to start with.

Comment 2

[:aceman]

Or maybe movemail does not issue the proper events that make that alert appear. E.g. I haven't found any equivalent of this http://mxr.mozilla.org/comm-central/source/mailnews/local/src/nsPop3Sink.cpp#882 to set biff state (new messages found).

movemail is quite stripped down in functionality. E.g. it has unimplemented CheckForNewMail (check if there are any messages but do not download them).

I can actually check out this theory.

Comment 3

[rsx11m]

Makes sense, if the Movemail code fails to set the biff status we can't expect the alerts to go off...

Comment 4

[:aceman]

Yes, when I added
 inbox->SetNumNewMessages(numNewMessages);
 inbox->SetBiffState(Ci.nsIMsgFolder.nsMsgBiffState_NewMail);

into nsMovemailService::GetNewMail() I got the new mail alert shown. But only once per TB session. I probably need to clear the state somehow to get a new alert at each msg download. Even when I increase the number of new messages in the SetNumNewMessages() call, I still do not get a new alert. Who could have an idea how these folder flags need to be managed?

Comment 5

[[e-mail]]

Normally the biff state is cleared when a new message is read. In particular I believe the action of reading a new message is supposed to call through to nsMsgDBFolder::OnHdrFlagsChanged which calls SendFlagNotifications which calls SetBiffState to clear the biff state again. This then trickles up to the status bar biff manager and the various platform-specific notifications.

Comment 6

[:aceman]

But what about the case when the new message is not read? I mean new messages come in, the user ignores that and another new message comes in. On POP3 I get the small popup alert at both incoming messages. I could not make that to work on movemail. Do I have to clear the biff state when new messages are incoming and then set it again?
Or are we OK if only the first incoming message after visiting the inbox shows the alert ?

Comment 7

[rsx11m]

(In reply to :aceman from comment #6)
> Or are we OK if only the first incoming message after visiting the inbox
> shows the alert ?

That's actually the behavior for IMAP account, though a bug should be pending to change that to showing the alert with each incoming message.

Comment 8

[rsx11m]

xref bug 414591 on that issue.

Comment 9

[[e-mail]]

I don't use POP3 so I was not aware of that behaviour.

Comment 10

[james.marchant]

This is still a problem with "movemail".

Comment 11

[Wayne Mery (:wsmwk)]

Support for Movemail has been removed as of version 87 per Bug 1625741