493478 - No new mail notification (biff) in browser for IMAP accounts

Status: NEW

(SeaMonkey :: MailNews: Backend, defect)

Description

[Jens Hatlak (:InvisibleSmiley)]

I'm initially filing this as a SeaMonkey bug because it is uncovered through SeaMonkey-only functionality but it might very well be MailNews Core in the end; see analysis below.

Bug 71105 introduced biff for new windows of any type. It doesn't work for IMAP accounts, though.

STR:
1. set IMAP account to be checked on startup
2. let Password Manager save correct password for IMAP account
3. set a Master Password (this is only needed to see that biff is actually run)
4. ensure mail.biff.on_new_window pref is set to true
5. ensure browser startup page doesn't trigger Master Password prompt
6. ensure only a browser window is opened at startup (any window other than MailNews would probably be OK as well)
7. ensure not to be in Offline mode
8. restart SeaMonkey

Expected results:
SeaMonkey should ask for the Master Password

Actual results:
No password prompt appears.

The above steps do trigger a Master Password prompt for POP3 accounts that are set to be checked on startup (and additionally have "Automatically download new messages" checked, cf. bug 94671). The Master Password prompt also appears if the MailNews window is opened and either the IMAP account, the POP3 account or both are setup to be checked at startup (again "Automatically download new messages" is required for the POP3 account).

Analysis:
- MailTasksGetMessagesForAllServers() in mailTasksOverlay.js is called in all three cases (IMAP, POP3, opening MailNews window):
  - from MailTasksOnLoad() for new windows of any type
  - from MsgGetMessagesForAllServers() called by loadStartFolder() for the MailNews window
- MailTasksGetMessagesForAllServers() has three parameters, aBiff, aMsgWindow and aDefaultServer. aBiff is TRUE for all three cases. aMsgWindow is NULL for the IMAP and POP3 cases but for the third case it's the MailNews window. aDefaultServer is irrelevant here.
- the actual mail check is performed through currentServer.performBiff() in the IMAP case and pop3Server.downloadMailFromServers() in the POP3 case (if the latter is commented out there is no Master Password prompt for POP3 any more).

Presumption:
I guess that pop3Server.downloadMailFromServers() somehow works correctly if its window parameter is NULL while IMAP's currentServer.performBiff() doesn't. This is C++ code, though with which I'm not too familiar. Someone with more expertise please take over!

Comment 1

[Robert Kaiser]

I don't see any reason to give this special priority, but it's also not unwanted, so cancelling the wanted flag.

Comment 2

[[e-mail]]

(In reply to comment #0)
> I guess that pop3Server.downloadMailFromServers() somehow works correctly if
> its window parameter is NULL while IMAP's currentServer.performBiff() doesn't.
My understanding was that the intention is that backend calls should not show UI unless they are passed in a msgWindow from a 3pane or standalone message window. I know some of the code that used to prompt anyway has already been removed but maybe this one got overlooked.

Comment 3

[Jens Hatlak (:InvisibleSmiley)]

(In reply to comment #2)
> (In reply to comment #0)
> > I guess that pop3Server.downloadMailFromServers() somehow works correctly if
> > its window parameter is NULL while IMAP's currentServer.performBiff() doesn't.
> My understanding was that the intention is that backend calls should not show
> UI unless they are passed in a msgWindow from a 3pane or standalone message
> window. I know some of the code that used to prompt anyway has already been
> removed but maybe this one got overlooked.

If what you say is right POP and anything else that still behaves like that should be changed to behave like IMAP, i.e. not prompt for a password when triggered by a non-MailNews window. When that happens this bug can be closed but until that time the whole functionality is broken because it's inconsistent and the user has no chance to understand the reasoning behind it.

Comment 4

[Mike Cowperthwaite]

The title of this bug matches the symptom I'm seeing with
  Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317
  Lightning/1.0b1 Thunderbird/3.0.4
but it doesn't match the behavior in comment 0 very well.

(In reply to comment #2)
> My understanding was that the intention is that backend calls should not show
> UI unless they are passed in a msgWindow from a 3pane or standalone message
> window.

Does this mean if I've got the message pane hidden, there wouldn't be notification?  Because I do often have it running with the pane turned off, due to TB's insistence on loading messages into the message pane that should not be (e.g. after selection Delete Mail Marked As Junk, or right-click on a message and Delete, when there is no message currently loaded).

Comment 5

[Mike Cowperthwaite]

The title of this bug matches the symptom I'm seeing with
  Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317
  Lightning/1.0b1 Thunderbird/3.0.4
but it doesn't match the behavior in comment 0 very well.

(In reply to comment #2)
> My understanding was that the intention is that backend calls should not show
> UI unless they are passed in a msgWindow from a 3pane or standalone message
> window.

Does this mean if I've got the message pane hidden, there wouldn't be notification?  Because I do often have it running with the pane turned off, due to TB's insistence on loading messages into the message pane that should not be (e.g. after selection Delete Mail Marked As Junk, or right-click on a message and Delete, when there is no message currently loaded).

Comment 6

[Mike Cowperthwaite]

Whoops, sorry about the double-post.

See also bug 471772.