Closed Bug 71105 Opened 24 years ago Closed 15 years ago

No new mail notification (biff) in browser until mail/news window has been opened at least once

Categories

(SeaMonkey :: MailNews: Message Display, enhancement, P2)

Product:
SeaMonkey
Component:
MailNews: Message Display
Type:
enhancement

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
seamonkey2.0a1

People

(Reporter: racham, Assigned: mnyromyr)

References

(Blocks 3 open bugs)

Details

(Keywords: relnote, Whiteboard: [need pref pane option, see comment #161])

Attachments

(2 files, 7 obsolete files)

326059: biff for all windows, v6 [checked in]
30.19 KB, patch
mnyromyr
: review+
mnyromyr
: superreview+
Details | Diff | Splinter Review
(Cv1) <mailnews.js> [Checkin: Comment 180]
1.17 KB, patch
neil
: review+
Bienvenu
: superreview+
Details | Diff | Splinter Review 
We need to be able to update the mail icon when there is new mail, without
having to appear start the messenger application. All thoe accounts which have
biff turned on and have passwords already avialable should be enriched with this
feature.
QA Contact: esther → sheelar
CCing myself on this one....
adding this bug to the main biff tracking bug
Blocks: biff
Will this bug also switch the icon for Unix'es?  When mozilla email is minimized
in FVWM2 it would be nice if the icon changed when new email arrived that same
way Netscape's icon changes.
*** Bug 77450 has been marked as a duplicate of this bug. ***
*** Bug 94503 has been marked as a duplicate of this bug. ***
*** Bug 94671 has been marked as a duplicate of this bug. ***
*** Bug 93783 has been marked as a duplicate of this bug. ***
This needs to be fixed for 1.0.  What good is email, if you do not know you
have received any?  I know on Solaris, if the email window is minimized, the
icon does not change to let you know you have email.  We should get this
to work like netscape and have the icon indicate status like biff.

How do we nominate this bug for 1.0 priority?
mozilla1.0. Adding some other keywords too.
Keywords: 4xp, mozilla1.0, nsbeta1
*** Bug 107769 has been marked as a duplicate of this bug. ***
reassigning to sspitzer
Assignee: racham → sspitzer
Keywords: nsbeta1 → nsbeta1+
Target Milestone: --- → mozilla0.9.9
Priority: -- → P2
reassigning to mscott. This will be part of the mail notification work he'll be
doing.
Assignee: sspitzer → mscott
Target Milestone: mozilla0.9.9 → mozilla1.0
Whiteboard: [ADT3]
marking nsbeta1-.
Keywords: nsbeta1+ → nsbeta1-
Whiteboard: [ADT3]
Target Milestone: mozilla1.0 → mozilla1.2
*** Bug 132003 has been marked as a duplicate of this bug. ***
I am sorry, but this is such a trivial and necessary future. I can't believe that it is targeted as 1.2. It should have been working by now... Why do I need to start Messenger to get my notifications. It was not like that in 4.7
adding self to cc list
Will the fix for this bug also affect the new messages popup checked in with the
Alert_Service_Branch?  The new message popup only appears when I open messenger
there, I want it to apply when I'm just browsing the web - is this the right
bug?  Thank you, and I apologize for the spam.
*** Bug 137899 has been marked as a duplicate of this bug. ***
*** Bug 137311 has been marked as a duplicate of this bug. ***
How closely is this tied to bug 134480 ?
QA Contact: sheelar → stephend
*** Bug 134480 has been marked as a duplicate of this bug. ***
This has regressed. In the past, biff at least worked if you had opened your
mail window once and closed it. Now, it never works at all unless you have the
mail window open constantly (which is unmeasurably stupid).
Keywords: mozilla1.0, nsbeta1- → mozilla1.1, nsbeta1, nsCatFood, regression
This still works if you had opened your Mail Application once and then closed
it. If you have only opened Browser and never opened Mail, it will not work.
Minused for Mach V RTM.  Will consider for Buffy.
Keywords: nsbeta1 → nsbeta1-
Actually I have not found this to be true. WinXP, latest nightly seems to only
fire biff if I have Mail/News open even if I previously opened and closed it. 
On Win98se if I open the mail then close it, it stops checking the mail. I have
to leave a mail window open at all times. Hard to believe this is still an open
bug after 1 1/2 years.
This stopped working for me when the animated new mail thingy was added. Since
then the only way biff fires if I keep Mail/News open.
Regarding comments #22,23,24,25, and 26, I have been seeing the same problem for
months on my POP3 account. Someone suggested to me that this was broken for POP3
accounts, but not for IMAP accounts, vis; IMAP will continue checking after you
close mailnews, POP3 will not check unless a mailnews  window is still open.

Can anyone with access to an IMAP account confirm/deny that rumor?
POP3 mail used to work fine as long as mail window was opened at least once. Now
it does not. This needs to change, currently biff is useless.
Gayatri, since you misunderstood the problem, I am renominating for nsbeta1.
Keywords: nsbeta1- → nsbeta1
James, IMAP V4 * OK dredd.mcom.com IMAP4 service (Netscape Messaging Server 4.15
Patch 4 (built Dec  7 2000)) appears to work fine on the trunk regarding mail
alerts/biff.  I'll check POP next.
So yes, this is working for IMAP on the trunk, but not POP3.
POP3 *doesn't* continue to fire notifications for me either, unless I keep a
mail window open on the *branch*, and I'm sure this is something that has
regressed recently.
I think this has been happening since late-March. See comments on bug 128851

Also, take a second look at the duplicates to this bug. I believe several of
them were filed because of this regression.
So if everybody agrees this is important and everybody agrees that it is not working, so how come the status is still new and how come Target is 1.2. I can't believe 1.0 was released without this fix, this is such a disgrace, this has been around forever...
This was working on Netscape 4.xx...
This should be something which will people switch to Mozilla over IE (Not having to run a second application for email). Now I have to keep my email window open all the time or I don't get my notifications
I agree but I don't think that this effects everyone. Maybe some don't use the
Mail/News or they just keep the window open? It's annoying to me actually but
it's the work around for now. I can't find the initial bug with my comments on
it right now, but I mentioned initially that this was a regression when the
animation code was checked in. I was told that just because this regressed that
didn't mean that the new code should be backed out...

At this point, I hope this can be changed to verified, the code change with the
above mentioned checkin checked and this bug fixed.

I'm afraid biff is more important than the animation; without biff the animation
is worthless anyway. It may have to be backed out.
Too bad. The animation is kinda cool and useful
*** Bug 158545 has been marked as a duplicate of this bug. ***
For a mac there is two check box:
When a new message arrive:
  x play a sound
  x display an alert

theese choice must work
*** Bug 149675 has been marked as a duplicate of this bug. ***
*** Bug 135878 has been marked as a duplicate of this bug. ***
*** Bug 159221 has been marked as a duplicate of this bug. ***
The summary should be changed as the current summary appears at first glance to
have nothing to with whether or not biff is actually working. Maybe chagning the
summary will reduce duplicates.

If someone disagrees with my changing the summary, go ahead and change it back.
Summary: If there is new mail, update biff icon on the browser toolbox without having to start messenger → No biff for POP3, and no icon update in browser for IMAP when no mail/news window open
The component should also be "Mail Notification" instead of Mail FE no?
'No biff for POP3' in the new subject doesn't seem appropriate.  What exactly do
you mean by this?  Biff works but has known has issues, (such as requiring a
restart if you enable/disable and/or change the interval value).
If you do not have a mail window open, biff doesn't work at all for me (20020722
trunk). Other posters have indicated the same. It doesn't matter if a mail/news
window has been opened or not.
Okay, I was an idiot when I parsed your new summary.

I parsed it as 'No biff for POP3' (not working in general), and 'no icon update
in browser for IMAP when no mail/news window open'. (for IMAP).

Perhaps (in order to eliminate points of possible confusion), we should
re-summarize as:

'biff/mail notification doesn't work without a mail window'?


I was trying to figure out a compact way of saying:

if (no mail window open) {
    no biff for pop3;
    no biff icon update in navigator window for imap;
    }

Forgive the pseudo-code. It's an easy way to exress logical relationships.
*** Bug 161801 has been marked as a duplicate of this bug. ***
OS: Windows NT → All
Hardware: PC → All
*** Bug 135878 has been marked as a duplicate of this bug. ***
Blocks: majorbugs
*** Bug 166128 has been marked as a duplicate of this bug. ***
*** Bug 166890 has been marked as a duplicate of this bug. ***
*** Bug 158862 has been marked as a duplicate of this bug. ***
------- Additional Comment #5 From Stephen Donner  2002-09-13 11:38 -------
Ah, wait, you don't have mail running? 
It's a known bug that mail has to be running to have alerts and notifications work.
That's bug 71105...
------- Additional Comment #6 From Michael K 2002-09-13 13:26 -------
Save me the trouble of figgerin' it out - isn't mail already running?
Please explain.
May save countless hours of newbie frustration because thier spam didn't arrive
on time   :)
------- Additional Comment #7 From Stephen Donner 2002-09-13 13:37 -------
Well, according to your comment:
>>In fact I get the "ding" and the "you have xx messages" text only AFTER I click
>>on the lower left mail icon......
you haven't launched mail yet.
So, indeed, this is a DUP of bug 
*** This bug has been marked as a duplicate of 71105 ***

 * * * * * * * 

OK  - So it's a DUPLICATE.

But that doesn't explain HOW and WHY the mail notification part DOESN'T WORK
like it is supposed to based on Netscape 4.whatever and every other browser that
has mail features.........Well?????

MRK


Why?

I'd say because some idiot checked in a patch that broke it. (We had it
partially working in the past so that once you'd started mail once, it would
keep checking mail as long as Mozilla was running.)
Flog the idiot with slabs of raw Spam and let's fix this!

Let's make Mozilla not only a good browser, but the best browser.  

(And woe to those who still think IE is adequate.....)
This broke when the animated notification was added. I mentioned that that 
code should be backed out since this regression was caused. I was told that 
just because this code broke that, didn't mean that it had to be backed out..

So, if you go back to when that was checked in, you can find what broke this. 
I don't recall when that was now, but it was just before 1.0..
Any idea on the time frame this will be fixed? Back at 1.0 it was stated to be
fixed for 1.2 alpha
*** Bug 171119 has been marked as a duplicate of this bug. ***
*** Bug 171824 has been marked as a duplicate of this bug. ***
reassigning to rdayal.
Assignee: mscott → rdayal
Looks like the fix will miss 1.2b. How about 1.1.1?
"Looks like the fix will miss 1.2b. How about 1.1.1?"

Why supporting TWO concurrent versions????   Maybe time to make 1.1.2 into 1.2c????
I'll be using 1.2b with or without the fix, but I suggest Mozilla to other
people who want more stability.
Status: NEW → ASSIGNED
Target Milestone: mozilla1.2alpha → mozilla1.3alpha
See 64947 for a list of cleanup items.
*** Bug 180305 has been marked as a duplicate of this bug. ***
Blocks: 128851
Blocks: MailNotification
*** Bug 128851 has been marked as a duplicate of this bug. ***
*** Bug 181595 has been marked as a duplicate of this bug. ***
Any chance we'll have a fix by 1.3a final (bug still exist with nighties)
I am sorry, but it is a disgrace that a bug like that has been open without being fixed since Spring of 2001. We are not talking a cosmetic bug here. It is a major deficiency. It is ridiculous.
Well, we missed 1.3a. How about 1.3b
I'm sorry if I keep posting here, but I'm really hoping that someone will
respond with an answer as to weather or not this bug is even being addressed. I
know how busy things can get, but this is a fairly large bug and since it was
"fixed" once and then reappeared when the nice new biff was introduced, it seems
like it could be fixed again. ;-)
Thanks for the great browser

I just looked at the Release Notes for Mozilla 1.2.1 and under "Known Problems
-> Mail and News" this bug isn't mentioned. Although leaving the mail window
open at all times is a work around, I still consider this bug a "Known Problem"
I've gotten to the point that when I see someone running Netscape with their
mail window closed, it looks weird.

http://www.mozilla.org/releases/mozilla1.2.1/#mail
Yes indeed. Adding relnote keyword.
Keywords: relnote
I have asked for inclusion into the next release notes.
Mail triage team: nsbeta1-
Keywords: nsbeta1-
Keywords: nsbeta1
*** Bug 189986 has been marked as a duplicate of this bug. ***
Perhaps if it was mentioned in the Release Notes, there wouldn't be so many
duplicates of this bug. A bug this LARGE going on for several months is a disgrace.
*** Bug 196876 has been marked as a duplicate of this bug. ***
".... A bug this LARGE going on for several months is a disgrace."

I agree.....  and this was written several months ago...  ;)


*** Bug 198650 has been marked as a duplicate of this bug. ***
Is there any chance at getting this problem fixed before the 1.4 series is done?
 If I'm going to have a program leave an icon in my taskbar, I'd like it to *do*
something besides speed the browser launch up by a few seconds; it should check
mail as it once did (before we had the sound notification)  If I can depend on a
very small third party program to leave an icon in my tray to do this, I know
that Mozilla must be able to.  This is a bug that should have been fixed a long
time ago.
It would appear that this bug was swept into the dust closet and forgotten. I
honestly can't believe that the Moz team would allow such a LARGE bug to go on
for so long. I was told a couple of months ago it would at least be included in
the Release notes, but that never happened.

The bug is assigned to Rajiv Dayal, but he has never made an appearence on this
bug.  The contact stephend@netscape.com isn't reading email. It would appear
there's nobody home on this bug.

People keep reporting this bug under different numbers, and the Moz team goes
"Oh that bug is already being dealt with under Bug 71105, reassign, next" and
the new bugs are sent to this blackhole. How do me end the loop?
	
RC68: 
Stephend is only QA and no developer. 
The people who are currently working on mailnews know about this bug.
We have limited developer resources and there is only one way to get it fixed in a 
very fast time : attach a patch and get reviews

before you add additional comments read : http://bugzilla.mozilla.org/etiquette.html
Matti,
Fast is not a word that should end up in any equation concerning this bug. This
bug has been going on for 2 YEARS and at least one year in it's current state. I
do not believe I have been rude and deserving of a repremand about etiquette. I
do believe that we the testers deserve at the least an explanation of what is
going on with this bug. Read through the post, I am not the only one bitching here.

This "bug" or better to say feature should be probably one of several features
which for now obviously also include Calendar (event, ... notification), 
Chatzilla (invitation to conference) and may be something else in the future.
For example, lack of such feature for Calendar undermines the whole purpose
of alarms - forgot to open Calendar and no alarms. Mozilla is a focal point
for such kind of add-ons and the browser is normally up. In such case we will
not miss events. It can be enhanced even more with some kind of daemons and
Windows services to catch Mozilla events.
Here's how it currently works in my version of Mozilla 1.2.1. I don't know if
there are any new messages so I click on the mail icon. The mail program opens
and  a sound plays to notify me of new messages. At the same time, the new
messages automatically download to my inbox. Of course the icon doesn't "know"
the messages have dl'd so I have to click the icon which activates the message
box "There are no new messages on the server". Of course not! They automatically
dl'd when I opened the mail program.
Keywords: mozilla1.1
Target Milestone: mozilla1.3alpha → ---
Jeff, please update to the nightly builds.

netscape employees: as I recall, animated mail notification was added into
netscape 6.2 as part of the xpication. 

just clarifying..

Sam
I cannot believe this bug is: 1) still not fixed after more than 2 years, 2)
still not listed in Known Problems in the release notes for 1.4a.  Is anyone
working on this problem?  I suggest a higher priority/severity level as it
appears nothing is happening at the current level.
I agree.  This bug has been in the pipeline for far too long.  Since 1.4 is 
going to be the stable, kill-all, milestone for some time, this bug should NOT 
BE ALLOWED to continue, as many end-user browsers will be based off of 1.4 and 
this is a basic feature that should have been fixed the week it was broken way 
back when.
Blocks: 133795
Maybe it's the "biff" term in the summary.  I knew what was before I started
using mozilla, but I thought it was just a unix utility name, not the name of
the concept of checking mail.  And win32 users won't know the term at all
(probably the largest group of people to be creating dup bugs).

I vote for a more descriptive summary.  How about:
"No new pop3/imap mail checking, icon update, or notification unless mail window
is open (ie, no checking if only browser windows are open)"

Yes, it's much longer, but it's also more likely to catch key words a user might
use.

This will be a non-issue once the mail part is made seperate from the browser
part.  (whatever name they end up with)

Has anyone looked at the patch from the bug that caused this regression?  Maybe
that can give a clue on what needs to be fixed.
From Additional Comment #91:
"This will be a non-issue once the mail part is made separate from the browser
part".
Why? It will be the same issue because it will be a kind of plugin to the browser.
And the same problem will be (and exists now) with such applications as
Calendar (which is already a separate application) which is useless without
notification (forgot to bring it up and missed tasks, appointments) and 
Chatzilla which definitely requires to show that you have invitation to chat.

tweaking the summary a little so that people who don't know who "biff" is will
be able to find this bug instead of filing more dups.

I have been poking around a little bit in 
http://lxr.mozilla.org/mozilla/source/lib/libmsg/biffmast.cpp to see if I can
spot how this is supposed to work, but unfortunately I don't expect to have time
to try to write a patch :(
Summary: No biff for POP3, and no icon update in browser for IMAP when no mail/news window open → No new mail notification (biff) for POP3, and no icon update in browser for IMAP when no mail/news window open
This bug has been resolved by fixing bug 205729. Maybe this one was invisible to
others, or was it of no interest to the guy it was assigned to? Maybe he's not
on board anymore and cavin@netscape.com (Cavin Song) had to take over to fix
this apparently minor issue in terms of work to be done in order to patch it?
Who knows, at least it works for me with the 2003052209 build.
If you test this: It does not check at startup, but after the time you have
configured in your account-settings.
Tested in 2003052309 on WinXP with POP3 account. It appears that it's no longer
a matter of mail/news be loaded *during* mail check, but mail/news must be
loaded at least once *before* mail check.
ie.
Startup in browser: no biff
From browser, open mail/news: biff works
Close mail/news (leaving browser still open): biff continues to work in browser.
In 2003060308 WinXP I'm still getting incorrect behavior, but better than before.

If I have new mail, I will get a new mail notification if I have the mail window
open, or if I have had the mail window open at least once and closed it. If I
start up the browser with a navigator window and do not open the mail window,
biff will not check for new mail. The behavior reverted to the way it was before
it got worse, but it is still incorrect and not working as well as it did in
Netscape 4.

I do agree that this bug should be reassigned. The assignee apparently has no
interest in the bug.
*** Bug 195273 has been marked as a duplicate of this bug. ***
On my Mozilla 1.4 under Win2K, Mozilla crashed when I double clicked on the Mail
Notification icon.  At this time, no Mail/News window was open and the IMAP mail
it was notifying me about was no longer new (i.e. it had already been read via
another agent).

I'm not reporting this as a separate bug as my copy of Mozilla is more than two
weeks old but this sounds relevant to an ongoing problem.
The mailer continues to pick up mail after the mailer pane has closed.  This 
seems to be a highly counterintuitive way of doing things - requiring a 
complete browser shutdown when you just want it to stop getting mail.

Perhaps this needs to be viewed?
  The mailer continues to pick up mail after the mailer pane has closed.  This
  seems to be a highly counterintuitive way of doing things - requiring a
  complete browser shutdown when you just want it to stop getting mail.

This behavior is correct and you have indicated that it is desirable by turning
on the "automatically check for new messages" option.
Response to Comment #100 :

> The mailer continues to pick up mail after the mailer pane has closed.  This 
seems to be a highly counterintuitive way of doing things - requiring a 
complete browser shutdown when you just want it to stop getting mail.

I absolutely disagree. Of course messenger is supposed to continue to check for
and fetch mail, if it is set up that way for the mail accounts and only the
browser window is open. It would be a serious flaw, if it wouldn't.

But I several times wish to have the option, to temporarily take offline only
the component from which I engage the Work Offline, while the other component
would stay online. 
F.e. taking offline messenger during long downloads, clogging my POTS line, to
prevent mess up of the *.msf files during autocheck, when dataflow isn't
sufficient for messenger or also sometimes just the other way around, freeze the
current state of all browser windows, so that autoreloads set by several tabs
(by extensions) or websites don't change the contnts of tabs any longer, but I'm
still able to continue reding NG and check for mail.
*** Bug 216365 has been marked as a duplicate of this bug. ***
*** Bug 218449 has been marked as a duplicate of this bug. ***
I'm a little baffled after reading this amazingly long thread, so this might not
be relevant/useful, but I wanted to CC myself and mention what happens on my
setup (Moz 1.5b/Linux):

I keep the mail window open all the time, though usually minimized.  It seems
like the sound notification always happens correctly, but there isn't any visual
notification nor is there any mention of such a notification in the prefs.

I came across this bug while searching for bugs about a taskbar/panel icon for
"new mail", which is what I'm really after: an icon "down by the clock" (as it
were) that appears when you have new mail, and disappears when you focus the
mail window.  (Eudora and Outlook on Windows have this.)
Anthony, that would be a different bug or request-for-enhancement.  I don't know 
how the various Linux desktops set up things like on-screen notifications, 
whether they have the equivalent of Windows' "tray" (which is where the 
notification icon appears).
Take a look at bug 137462, which is a request to change the desktop icon of the 
(running) mail window when new mail arrives; that would presumably apply to all 
platforms.

Regarding the actual problems this bug is intended to address:  Where did the 
IMAP issue come from?  Jerry Baker changed the summary (back around comment 44)
to specify this problem, but I see no earlier discussion of that point.

I interpret that description as: in the Navigator window's Component bar, the 
mail icon does not get a green arrow on new (IMAP) mail when no mail window is 
open.  Presumably, since this was distinguished from POP, the systray 
notification *was* taking place for IMAP with no mail window open.

Was this ever actually a problem?  Is this a current problem?  (I don't have an 
IMAP account to play with.)  Could it be theme-dependent?

Perhaps more of interest, regarding this bug:  Does IMAP mail-checking occur if 
no mail window has ever been opened, or does it (like POP) require that the mail 
window has been opened at least once?

If the IMAP/Component icon issue is vapor, and mail-checking for POP and IMAP 
behave the same w.r.t. the mail-window status, then the summary on this bug 
could be made much more concise and accurate.

Changing to Mail Notification component.
Component: Mail Window Front End → Mail Notification
Mike, in recent GNOME and KDE versions there is a system notification area, a
kind of SysTray from Windows. i believe is a kind of standardisation from
www.freedesktop.org
What are you going to do, link Mozilla with Gnome2 and KDE libraries?  That
would be rediculous.  And it wouldn't do any good whatsoever for people not
running those desktops.  Linux (actually all UNIX-like targets of Moz) has no
guarantee that any particular window manager or desktop environment is going to
be running.  Doing things that only work with a particular subset would be
pointless.

AFAIK, for IMAP checking, the is no check unless a mail window is open.  This is
a regression from Netscape 4.
Two additional comments on this bug regarding Moz 1.5 RC2:

1. I can confirm that IMAP mail checking does occur if only the browser window
is open, but it "appears" that the mail window must be opened at least once
before checking begins.

2. Custom wave file doesn't play on IMAP mail arrival even though all biff
variables appear to be properly set in about:config. System beep does work
properly if selected.

Hope this is the right bug to report on.

J. Gross
John Gross: a question regarding IMAP notification: if only the browser window 
is open (after having had the mail/news window open once), and new mail arrives: 
specifically which notifications are you seeing?  In particular (per the summary 
of this bug) does the green new-mail flag appear in the browser's component bar?

Regarding sounds: bug 211223 has been filed for notification sounds under Linux, 
pointing back to an earlier bug that was purported to be fixed; bug 214937 was 
filed (as a Windows bug) for custom WAVs.
Response to comment #110:

Following observed using Mozilla 1.5 RC2 (Modern Theme) under Mandrake 9.1
(KDE), independent POP3 and IMAP accounts displayed in mail client:

1. If only mail client is opened and mail fetched automatically on startup, then
NO green arrows appear on any IMAP icons displayed in the folder tree on the
left side of the client window. The green arrows DO APPEAR on new IMAP message
icons in the message list pane at the top right of the client window. The POP3
icons DO DISPLAY green arrows in both the folder tree and message panes if new
messages are fetched on startup.

2. While mail client is open and mail is periodically fetched automatically,
then green arrow DOES APPEAR on IMAP account name icon in folder tree and on the
icons of any new messages in message list pane. Arrow does NOT APPEAR on icon of
IMAP account inbox folder in folder tree.

3. If mail client opened first w/auto fetching on startup, then browser opened,
then mail client closed, "mozilla" continues to fetch mail. The mail client icon
on component bar of browser displays downward pointing green/white arrow on
receipt of mail even though mail client is closed. If component bar icon is
clicked, the mail client is displayed w/new messages in message list pane. New
message icons display green arrows. There are NO green arrows on IMAP account
name icon or inbox icon in folder tree list.

4. If only browser is first opened then mail is never fetched. When mail client
is eventually opened (after browser) then fetching begins and continues as in #3
above. In this case, on initial display of mail client with automatic mail fetch
on startup, both the component bar mail icon and all IMAP account folder tree
icons DO NOT display green arrows although the new message icons DO display
green arrows. This behavior only occurs with IMAP since under same conditions
POP3 accounts display green arrows on all icons under appropriate circumstances.

J. Gross
*** Bug 227744 has been marked as a duplicate of this bug. ***
*** Bug 238232 has been marked as a duplicate of this bug. ***
I've recently obtained an IMAP account to test with (at fastmail.fm).  I'm 
attempting to duplicate the symptoms described by John Gross in comment 111.

Regarding the symptoms pertinent to this bug, I see the same symptoms he does: 
the biff notification (browser's component bar icon, systray icon, alert) is 
displayed for new mail in the IMAP account, so long as the mail window has been 
opened at least once.  This is identical to the POP symptom.  I'm updating the 
summary of this bug for accuracy.


Comment 111 additionally talks about the 'new' arrows failing to appear on the 
folder, and in some circumstances, on the account.  I see the same symptom for 
the folder, but the account always gets the 'new' arrow, regardless of whether 
or not the mail window is open at the time of the new-mail fetch.  I've opened 
bug 238281 for the failure to flag the Inbox.
Summary: No new mail notification (biff) for POP3, and no icon update in browser for IMAP when no mail/news window open → No new mail notification (biff) in browser until mail/news window has been opened at least once
mozilla 1.7/windows XP....same problem. 
*** Bug 243907 has been marked as a duplicate of this bug. ***
Why is it that as of this release (1.8a1) this has still not been fixed.  Also,
somewhat related to this bug, when you open mail, you cannot "check mail"
manually until the app checks for the presence of mail and notifies you, or
doesn't find any.  After which time, you can click "Get mail" and it will work.
 For example, you open Mozilla.  No mail notification is sent.  Then you open
mail.  Then you have to wait for it to check to see if there is mail, and after
being notified with stupid pop-up, you can finally get the new mail by clicking
the button.  Then you close mail.  At this point, if you get new mail, it will
eventually notify you (since mail was loaded once?).  So the popup goes away,
and you open mail.  Then you have to wait for it to check again, and notify you
before clicking get mail will produce results.  This is juvenile behavior, and
has been going on release after release.  I am no programmer, but I wouldn't
think that this should take years to resolve.  Is anyone working on this?
I actually consider this a feature: I don't want Mozilla to poll my mail
accounts when I open just a browser window. I find it quite appropriate that
when I want to know the status of my mail, I have to open the Mail window
explicitly at least once; in fact, I would prefer if Mozilla *stopped* polling
mail accounts when I close the Mail window but I still have some browser windows
around. I wouldn't mind, however, if there was a "Check for new mail" item in
the Tools menu or thereabouts.
I think that the best solution would be a very small and light application
similar to the old nsnotify or the traditional Unix biff. I have been using
nsnotify until recently but it was not integrated with Mozilla. When I had
Mozilla opened I had two icons in the tray bar.
Well, if you have notifications selected in the Preferences -> Mail & Newsgroups
-> Notifications section, it should poll and notify.  But if you don't, then
obviously it should not.  The whole point is that you don't have to remember to
check for mail, it will let you know if there is new mail.

I also don't believe a separate app is the answer.  This is a listed
functionality of the program, it should work properly on its own.

Matt
The netscape did this very will. would like to see it back. the last version of
netscape that did it was version 4.8. Would love to see it in mozilla. That was
the one thing I loved about netscape.
I agree David.  That was one great feature of Netscape 4.8 that I want to see
returned.
That's why I kept it around for so long. I really miss that feature. They would
make a lot of people happy by bring it back.
Windows 98se, PIII, 769 MB, Moz 1.6.  Great program.

I have 500 to 600 email folders (!), and yes, I'm using the Filters function.

I just clicked through all of my folders.  A couple dozen of them had unread
mail, but the folders were not labeled in BOLD.

I didn't even know they had unread mail in them!  One was "Bugzilla Account Info!"

Unfortunately, it's been a few months since I remembered to manually check
through all the folders.  Some unrecognized emails were significant.

Best luck,
           -Neil-
(In reply to comment #124)
OS/2 Warp4 +FP16, K4-2+/500, 640 MB, Moz 1.7. 
> 
> I have 500 to 600 email folders (!), and yes, I'm using the Filters function.
 
I got only some 25 of them

> I didn't even know they had unread mail in them!  One was "Bugzilla Account Info!"

Just had the same experience. No indication whatsoever that there is any new,
unread mail, until I expanded the Inbox of that one account to then finally see
the bold folder title and number of new mails - and yes, it also was the
Bugzilla folder with new mails in it, dating back up to 7 days now.
comment 124 and comment 125 both describe a different bug. This bug has nothing
to do with folders, this bug is about the lack of mail notification when the
mail window is not even open yet (though if anybody can find the bug number for
the lack of notification for sub-folders posting that bug number here would be
helpful)
(In reply to comment #121)
> The netscape did this very will. would like to see it back. the last version of
> netscape that did it was version 4.8. Would love to see it in mozilla. That was
> the one thing I loved about netscape.

I agree 4.8 worked great, when the browser was open it checked for new mail.
Thats the way it should be. You should not have to check the mail, for the mail
to ckeck the mail.   gary@aguanga.net
*** Bug 253208 has been marked as a duplicate of this bug. ***
*** Bug 254154 has been marked as a duplicate of this bug. ***
Product: Browser → Seamonkey
No longer blocks: majorbugs
This bug still seems to exist with Mozilla 1.7.11! At least that's what I see
here with the OS/2 version Mozilla/5.0 (OS/2; U; Warp 4.5; de-AT; rv:1.7.11)
Gecko/20050728.
Would someone please finally fix this 4 years old, very annoying inconvenience?
(In reply to comment #130)
> Would someone please finally fix this 4 years old, very annoying inconvenience?

Please read the bugzilla etiquette page
<https://bugzilla.mozilla.org/page.cgi?id=etiquette.html>.
Comments not related to fixing the bug aren't appropriate. Thanks. :-)
OS/2? wow. uh....

there's no "blocking-1.8b4" or similar flags. So I have no idea what the OP
should set (er. actually. the OP can't set anything, I think.... it's a former
Netscape employee >_<).

speaking of which, you have to be kidding me! The reporter, QA, and Assigned-To
are all former Netscape employees! It could be that nobody important is watching
this bug... file a dupe and see if it gets recognized as one. If so, well,
please -- holy **** -- fix this bug!

that said. uh. what was the original intention? make it possible to minimize the
mailnews client and get mail notifications (which I think it does)? or, to close
the window in mozsuite and still get mail (which it doesn't)?

uh. anyways. on the positive side, this bug would have to be stagnant for 6
years before it became a problem of Microsoft proportions. yes, I'm referring to
the PNG bug that may finally get fixed in IE7. but sheesh. 6 years. took em long
enough.

and it just occured to me. there is no more mozsuite, so this may just as well
be RESOLVED WONTFIX since it doesn't apply to thunderbird. that's a bad idea,
but I think that as soon as enough current maintainers see this bug, it will
probably be RESOLVED WONTFIX due to the fact that if it is fixed, nobody
important will see it (well... uh... are they still going through with the
seamonkey project releases? if so, ignore what I just said)
people do read these bugs. in fact, so many people read these bugs that it 
makes bugzilla sick. the next person to volunteer more useless information will 
be assigned this bug (normally i'd just give the bug to the first person who 
annoyed me, which appears to be wolfi).
Assignee: rdayal → nobody
Severity: normal → enhancement
Status: ASSIGNED → NEW
Keywords: helpwanted
QA Contact: stephend → mail
(In reply to comment #132)
> OS/2? wow. uh....
> 
> there's no "blocking-1.8b4" or similar flags. So I have no idea what the OP
> should set (er. actually. the OP can't set anything, I think.... it's a former
> Netscape employee >_<).
> 
> speaking of which, you have to be kidding me! The reporter, QA, and Assigned-To
> are all former Netscape employees! It could be that nobody important is watching
> this bug... file a dupe and see if it gets recognized as one. If so, well,
> please -- holy crap -- fix this bug!

I'm watching this bug (I'm the former QA contact @ Netscape for this), and do
indeed hope it gets fixed for SeaMonkey at some point.
 
> that said. uh. what was the original intention? make it possible to minimize the
> mailnews client and get mail notifications (which I think it does)? or, to close
> the window in mozsuite and still get mail (which it doesn't)?

The intention is pretty simple:

Without ever having to open the Mail & Newsgroups portion of the suite
application, your previously-existing preferences to notify should be honored
and reflected by both system tray notifications and by the designation of a
green arrow over the envelope icon in the component bar.

<snipped rabbit-trail expression re: Microsoft's bugs>
 
> and it just occured to me. there is no more mozsuite, so this may just as well
> be RESOLVED WONTFIX since it doesn't apply to thunderbird. that's a bad idea,
> but I think that as soon as enough current maintainers see this bug, it will
> probably be RESOLVED WONTFIX due to the fact that if it is fixed, nobody
> important will see it (well... uh... are they still going through with the
> seamonkey project releases? if so, ignore what I just said)

While not wanting to side-track myself, I'll just state that those of us
actively working on the SeaMonkey suite want to ensure the best user-experience
possible given our resources.  That said, fixing this would probably require
core mail code shared with Thunderbird to be changed, and might present various
challenges. (I'm not a programmer, so take that statement with a grain of salt.)

As you can see already, this bug is quite large enough as it is; let's please
limit future comments to actual programming-level implementation issues, as
anything else simply adds to the amount of 'information' to wade through.

Thanks.
Severity: enhancement → normal
Keywords: helpwanted
QA Contact: mail → stephend
(In reply to comment #132)
> OS/2? wow. uh....
> 
> there's no "blocking-1.8b4" or similar flags. So I have no idea what the OP
> should set (er. actually. the OP can't set anything, I think.... it's a former
> Netscape employee >_<).
> 
> speaking of which, you have to be kidding me! The reporter, QA, and Assigned-To
> are all former Netscape employees! It could be that nobody important is watching
> this bug... file a dupe and see if it gets recognized as one. If so, well,
> please -- holy crap -- fix this bug!

I'm watching this bug (I'm the former QA contact @ Netscape for this), and do
indeed hope it gets fixed for SeaMonkey at some point.
 
> that said. uh. what was the original intention? make it possible to minimize the
> mailnews client and get mail notifications (which I think it does)? or, to close
> the window in mozsuite and still get mail (which it doesn't)?

The intention is pretty simple:

Without ever having to open the Mail & Newsgroups portion of the suite
application, your previously-existing preferences to notify should be honored
and reflected by both system tray notifications and by the designation of a
green arrow over the envelope icon in the component bar.

<snipped rabbit-trail expression re: Microsoft's bugs>
 
> and it just occured to me. there is no more mozsuite, so this may just as well
> be RESOLVED WONTFIX since it doesn't apply to thunderbird. that's a bad idea,
> but I think that as soon as enough current maintainers see this bug, it will
> probably be RESOLVED WONTFIX due to the fact that if it is fixed, nobody
> important will see it (well... uh... are they still going through with the
> seamonkey project releases? if so, ignore what I just said)

While not wanting to side-track myself, I'll just state that those of us
actively working on the SeaMonkey suite want to ensure the best user-experience
possible given our resources.  That said, fixing this would probably require
core mail code shared with Thunderbird to be changed, and might present various
challenges. (I'm not a programmer, so take that statement with a grain of salt.)

As you can see already, this bug is quite large enough as it is; let's please
limit future comments to actual programming-level implementation issues, as
anything else simply adds to the amount of 'information' to wade through.

Thanks.
Severity: normal → enhancement
Keywords: helpwanted
QA Contact: stephend → stdonner
ah, okay. I saw all of the formerly-netscape.com.tld and thought "gee, they
can't get mail at those addresses..."

anyways, okay, then the purpose does make sense, and it is a useful feature. I
have no idea how Gecko's implemented, so I have no idea where to start
discussing implementing it, so I'll hush up :).

and sorry if I sounded like the age of the bug was somehow reflectant on
MoFo/MoCo's performance ;p I know how bugs are. Sometimes the problem is simple,
but a fix that doesn't break other things (and that works on every possible
configuration) is hard.

Right, well, I'll stop bugspamming everyone and let the programmers have a whack
at it.
Attached patch quick and dirty patch (obsolete) — — Splinter Review 
quick and dirty hack

To make this not suck, the following two things must be done at a minimum:
1. Add a pref, with UI for the pref, so this code can be turned off.  I'm not sure whether it should default to being on or off.
2. Don't do a wholesale copy of the MsgGetMessagesForAllServers function - find a way to share the code.
3. Figure out if this currently does something silly for pop servers.

I'd like feedback on this approach before cleaning the patch up.
what happens if we load mailnews at startup? Will we do a double biff on startup?
(In reply to comment #138)
> what happens if we load mailnews at startup? Will we do a double biff on
> startup?
> 

If it did, it was not apparent when I tested.
(In reply to comment #139)
> (In reply to comment #138)
> > what happens if we load mailnews at startup? Will we do a double biff on
> > startup?
> > 
> 
> If it did, it was not apparent when I tested.

David, how would I tell if it is doing something bad here?
if you're running a debug build, and don't get any assertions triggering, then that's a good sign. Doing a pop3/imap protocol log and making sure we don't try to connect to the pop3/imap server twice on startup could also be helpful.
(In reply to comment #141)
> if you're running a debug build, and don't get any assertions triggering, then
> that's a good sign. Doing a pop3/imap protocol log and making sure we don't try
> to connect to the pop3/imap server twice on startup could also be helpful.

No asserts... I can check an IMAP log tonight when I look up how to do the logging.
(In reply to comment #141)
> if you're running a debug build, and don't get any assertions triggering, then
> that's a good sign. Doing a pop3/imap protocol log and making sure we don't try
> to connect to the pop3/imap server twice on startup could also be helpful.

I only see one connection to the server, and it looks pretty much the same with/without the patch, and whether or not I start mailnews when the patch is applied.

Other than factoring out common code in this function and the function I copied from, is there anything else I need to do before attaching a cleaned up patch and requesting r/sr for real?
(In reply to comment #143)
> Other than factoring out common code in this function and the function I copied
> from, is there anything else I need to do before attaching a cleaned up patch
> and requesting r/sr for real?
> 

..and adding UI/prefs of course... I'm just asking about the backend part.
nothing else, as far as I'm concerned...but it's more up to the Seamonkey folks...
(In reply to comment #145)
> nothing else, as far as I'm concerned...but it's more up to the Seamonkey
> folks...

bienvenu, excellent, thanks.

Neil, if you don't enter your password the first time, how do I keep from prompting again with every new window?
(In reply to comment #146)
>Neil, if you don't enter your password the first time, how do I keep from
>prompting again with every new window?
When the status bar biff manager service starts its biff state defaults to unknown. There is no code that sets the state to unknown, although on branch it should do in case of profile switching. If your startup code queries the biff state and finds that it's unknown it could set it to no mail, then biff.
Assignee: nobody → mail
QA Contact: stephend
Comment on attachment 230291 [details] [diff] [review]
quick and dirty patch

I'm OK with this, but you'll definitely need a SeaMonkey person. One nit - MAM is an odd var name - a more common abbreviation is "am", or since you only use it once, you don't really need a var for it.
Attachment #230291 - Flags: superreview?(neil)
Attachment #230291 - Flags: review?(bienvenu)
Attachment #230291 - Flags: review+
Comment on attachment 230291 [details] [diff] [review]
quick and dirty patch

The patch as provided seems to be missing the pop3 coalescing function but I'm assuming that will all be fixed along with the other issues in comment 137.
Attachment #230291 - Flags: superreview?(neil) → superreview+
Can somebody take this bug the rest of the way?  I haven't done any development work in months (and no longer have an environment set up).
I could if I'd understand what "the pop3 coalescing function" in comment 147 is meant to be. ;-)
if I remember correctly, pop3 coalescing refers to the fact that when we're doing a bunch of get new mails, and several pop3 servers share the same inbox, we want to serialize those urls so that, for example, we don't have 5 pop3 servers trying to write into the local folders inbox at the same time.
Attached patch unbitrot plus first improvements (obsolete) — — Splinter Review 
This patch:
- splits off the JS code from mailTasksOverlay.xul into mailTasksOverlay.js
- moves the needed functions into mailTasksOverlay.js as well
- does *not* use a pref to control this (yet) - I'm not convinced yet it is needed
- is actually WIP, but I need some first reviews to pave the direction this should go.

Taking.
Assignee: mail → mnyromyr
Attachment #230291 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #323318 - Flags: superreview?(neil)
Attachment #323318 - Flags: review?
Attachment #323318 - Flags: review? → review?(bugzilla)
Comment on attachment 323318 [details] [diff] [review]
unbitrot plus first improvements

What seems to be doing is downloading all new mail whenever you open a window, which seems unreasonable to me unless it's controlled by a pref.

It's also still unclear what happens when you open a mail window, particularly if you log in to an IMAP server by default.
Good point. And I need to look into memory footprint as well - loading the mail libraries when not using mailnews at all will get memory hog hunters screaming. ;-)
Anything else?
>+      var biffManager = Components.classes["@mozilla.org/messenger/statusBarBiffManager;1"]
>+                                  .getService(Components.interfaces.nsIStatusBarBiffManager);
This moved code already loads the base mail library - but if you thought that was bad, I seem to remember that a mailto: link effectively loads all of mail.
Attached patch biff for all windows, v2 (obsolete) — — Splinter Review 
Updated version:
- Use default pref("mail.biff.on_new_window", true); to control whether biff should be performed on each window load or not. 
- Minor cleanup and a typo fix.

Even without this patch, my debug build loads 5 mailnews libs when started with -browser, opening a mailto link will load 4 more for a total of 9.
With this patch and mail.biff.on_new_window=false, the number remains at 5.
With this patch and mail.biff.on_new_window=true, the number raises to 9.
Opening the mailnews window will load some for for a total of 13 libraries.


(In reply to comment #154)
> (From update of attachment 323318 [details] [diff] [review])
> What seems to be doing is downloading all new mail whenever you open a 
> window, which seems unreasonable to me unless it's controlled by a pref.

Fixed.

> It's also still unclear what happens when you open a mail window, 
> particularly if you log in to an IMAP server by default.

I don't understand. If I biff an IMAP account and then open mailnews, I get 

  imap://xxxxxx@imap.xxxxxx.de...skipping, already opened

at the shell...
Attachment #323318 - Attachment is obsolete: true
Attachment #323318 - Flags: superreview?(neil)
Attachment #323318 - Flags: review?(bugzilla)
Attachment #323444 - Flags: superreview?(neil)
Attachment #323444 - Flags: review?(bugzilla)
My point is that loadStartFolder already biffs all accounts...
Keywords: helpwanted, regression
Attached patch biff for all windows, v3 (obsolete) — — Splinter Review 
Next incarnation:
- Only try to biff if there isn't already a MailNews main window.
- Minor cleanup..

In fact, we even could _not_ biff if there _has_been_ a MailNews main window, but that's probably too hard to detect - and the additional biff doesn't hurt too much in that case...
Attachment #323444 - Attachment is obsolete: true
Attachment #323444 - Flags: superreview?(neil)
Attachment #323444 - Flags: review?(bugzilla)
Attachment #323588 - Flags: superreview?(neil)
Attachment #323588 - Flags: review?(bugzilla)
(In reply to comment #159)
> In fact, we even could _not_ biff if there _has_been_ a MailNews main window
Why not biff only if the biff state is unknown? (After you start, biff then automatically updates according to preferences any, right?)
Comment on attachment 323588 [details] [diff] [review]
biff for all windows, v3

I wonder why localFoldersToDownloadTo isn't a regular JS array?

We could do with some pref UI for this ;-)
Attached patch biff for all windows, v4 (obsolete) — — Splinter Review 
(In reply to comment #160)
> Why not biff only if the biff state is unknown?

Well, this helps only if biff already detected new mail, but unfortunately "NoMail" is not always set correctly, so we'll still do some unnecessary checking. I Implemented that check now nonetheless.

(In reply to comment #161)
> I wonder why localFoldersToDownloadTo isn't a regular JS array?

No idea, probably some legacy. Fixed.

> We could do with some pref UI for this ;-)

I'd rather do that in a separate patch (afterwards).
Attachment #323588 - Attachment is obsolete: true
Attachment #323588 - Flags: superreview?(neil)
Attachment #323588 - Flags: review?(bugzilla)
Attachment #324227 - Flags: superreview?(neil)
Attachment #324227 - Flags: review?(bugzilla)
Comment on attachment 324227 [details] [diff] [review]
biff for all windows, v4

>+pref("mail.biff.on_new_window", true);
I'd better turn this off now on all my profiles so I don't get surprised ;-)

>+  const MSG_FOLDER_FLAG_INBOX = 0x1000; // XXX will be killed by bug 436044
That reminds me, I need to poke a reviewer (or two) :-(

>+    // parallel isupports array of folders to download to...
>+    var localFoldersToDownloadTo = [];
No isupports here ;-)

>+  catch(ex)
>+  {
>+    dump(ex + "\n");
Components.utils.reportError perhaps?

>+  catch (ignoredDetail)
>+  {
>+    // treat missing prefs etc. as "don't perform biff"
How will that happen? (Unless you don't check the pref entry in yet?)

>+  // If we already have a defined biff-state set on the taskOverlay icon,
Maybe ask the biff manager directly?

>+  // Unfortunately, BIFF_STATE_UNKNOWN may be set even if biff is running...
Should we write a setter for the biff state? (In theory you could call onItemIntPropertyChanged but that's a bit of a hack!)
Attachment #324227 - Flags: superreview?(neil) → superreview+
Hi Karsten, I'm happy you are working on this feature, it should be very nice. 

Functionally, I've always envisioned this feature as doing, at SeaMonkey startup, what the initial opening of the mailnews window does in terms of getting mail checking going, without actually opening the window (or any side effects that would clear new flags, etc.)  

I applied attachment 324227 [details] [diff] [review] to Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9pre) Gecko/2008061009 SeaMonkey/2.0a1pre.  On a very quick check, it seems to work with server settings 
[x] check for new messages at startup
[x] check for new messages every [ 2] minutes.

However, if I don't have the startup option checked, this feature does not seem to work, based on it never asking for passwords, which I'd cleared.  I have this configuration due to bug 344066, which may render this feature less useful than it might otherwise be.   (Bug 34066#4 suggested clearing the startup option.)

I'm out of time, will try to test more tomorrow night.
(In reply to comment #164)
> However, if I don't have the startup option checked, this feature does not seem
> to work, based on it never asking for passwords, which I'd cleared.  I have
> this configuration due to bug 344066, which may render this feature less useful
> than it might otherwise be.
So, maybe opening MailNews should check the biffstate too (i.e. move the check into MailTasksGetMessagesForAllServers)?
Comment on attachment 324227 [details] [diff] [review]
biff for all windows, v4

+addEventListener("load", MailTasksOnLoad, false);

For some reason, this is getting called twice for starting up with a browser window. I'm not sure if that's a problem or not.

Also I started up with an account which has an invalid server. It didn't prompt me like the mailnews window does, is that expected?
(In reply to comment #166)
> For some reason, this is getting called twice for starting up with a browser window.
Once for the Mac's hidden window perhaps?
Yes, it's the hidden window. 
And you get that regardless of with which window you start on Mac, not just for the browser (it's just hidden among console spam).
I'll tackle the comments soon.
Attachment #324227 - Flags: review?(bugzilla)
(In reply to comment #163)
> >+  // Unfortunately, BIFF_STATE_UNKNOWN may be set even if biff is running...
> Should we write a setter for the biff state? (In theory you could call
> onItemIntPropertyChanged but that's a bit of a hack!)

JFTR: (Part of) The actual problem is bug 113366:
<http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/mailnews/base/util/nsMsgDBFolder.cpp&rev=1.345&mark=3774-3776,3786-3787#3770>
This suppresses updating the biff state from unknown to nomail. :-(
Attached patch (broken patch file) (obsolete) — — Splinter Review 
This addresses most of Neil's comment #163:
- Asking biff manager directly won't change anything, it has already been asked by explicitly calling the observer. 
- Bug 113366 introduced some biff optimizations, including:
  - it initializes incoming servers' biff state to no_mail (instead of unknown)
  - it doesn't notify for changes from unknown to no_mail
  These made us not get notified at all, leaving our biff handling in a false 
  undefined state.

I couldn't reproduce Rich's problem with not getting asked for passwords with the patch, so please try again with this one. ;-) 

The hidden window on Mac also tries to initialize this all, but since it doesn't have a mini-mail icon, we return early without any harm done.

Rerequesting r/sr for the core changes of biff initialization, which are new in this incarnation.
Attachment #324227 - Attachment is obsolete: true
Attachment #326056 - Flags: superreview?(bienvenu)
Attachment #326056 - Flags: review?(neil)
Attached patch biff for all windows, v5 (obsolete) — — Splinter Review 
This time with -N. :-(
Attachment #326056 - Attachment is obsolete: true
Attachment #326056 - Flags: superreview?(bienvenu)
Attachment #326056 - Flags: review?(neil)
Attachment #326059 - Flags: superreview?(bienvenu)
Attachment #326059 - Flags: review?(neil)
Attachment #326056 - Attachment description: biff for all windows, v5 → (broken patch file)
Comment on attachment 326059 [details] [diff] [review]
biff for all windows, v5

>+  if (!inbox)
>+    return; // ignore servers without inboxes
I'm not sure it's possible for a pop3 server not to have an inbox ;-)

>+  if (miniMail.getAttribute("BiffState") != BIFF_STATE_UNKNOWN)
>+    return;
IMHO you should read the biff state from the biff manager, the same way that the icon updating code does.
Attachment #326059 - Flags: review?(neil) → review+
Attachment #326059 - Flags: superreview?(bienvenu) → superreview+
Addressed Neil's final comments, took over r+/sr+ and checked this in into CVS trunk aka 1.9.0.
Leaving bug open for related pref pane work (see comment #161).
Attachment #326059 - Attachment is obsolete: true
Attachment #326359 - Flags: superreview+
Attachment #326359 - Flags: review+
Whiteboard: need pref pane option, see comment #161
Depends on: 442251
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.0.1pre) Gecko/2008070203 Thunderbird/3.0a2pre] (nightly) (W2Ksp4)

TB doesn't care for this preference.
Attachment #328155 - Flags: superreview?(bienvenu)
Attachment #328155 - Flags: review?(neil)
(In reply to comment #173)
> Leaving bug open for related pref pane work (see comment #161).

I would suggest to resolve this one and file a follow-up bug.
Target Milestone: --- → seamonkey2.0alpha
No longer blocks: 128851
Had some time to play with this one today, using the current trunk nightly, Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.2pre) Gecko/2008070501 SeaMonkey/2.0a1pre.

I started out two pop accounts (on different servers) with passwords not saved in Password Manager and both set to:
[x] Check for new messages at startup
[x] Check for new messages every [1] minutes.  (2 min for the 2nd account.)

When I launch SM with mail.biff.on_new_window true, I consistently get a password dialog box that bounces down then back up before I can even see which account it is for, then normal (they actually wait) password boxes in succession for the first and second accounts.   Polling for each account was seen on the wire as soon as the password was entered.  (I was monitoring with Wireshark, formerly Ethereal.)

When I cleared Check...at startup for both [NOTE 1!], I got the same result as comment #164, there was no prompting for passwords (and, of course, no polling.)   Prompting and polling only started when the mailnews window was opened.  I wonder what the difference between Karsten's setup and mine could be? (comment #170)   Furthermore, when I did finally open MN myself, there was still no prompt or polling.  Setting biff.on_new_window false and restarting didn't work either when I eventually opened MN.   Something is borked here...

In a configuration with both checks back on, biff_on_new_window true and the passwords in PM, things seem to work pretty much as expected.   Polling starts as soon as SM does.   With Check...at startup off, polling starts after the appropriate delays.  

Bug 344066 still seems to ruin the effect of this enhancement, losing New flags in the second account if Check...on startup is enabled.  I'm tempted to make that bug block this one because of that.   However, running with delayed start is a usable configuration and has the advantage of less of a circus at SM startup.  So this is gonna be nice, even without 344066 fixed.   I'll be doing more testing...


Since I see no new bug for UI and no commentary here about a new bug, I guess I'll just dive right in.  :)  Seems to me that a good place to add this might be  Pref > Appearance :
When SeaMonkey starts up open
 [x] Browser
 [ ] Mail & Newsgroups
 [x] Mail checking (no window)
 [ ] Composer
 [ ] Address Book
 [ ] Chatzilla

If M & N is selected, the checking option could be grayed out, I suppose.   One thing I think that would be neat would be to do a windowless startup, i.e. deselect Browser in the above so no windows open.  (I tried - got a browser window anyway.)  You could add SM to the login scripting and it would silently begin looking for mail.   Another UI(?) option might be command line switches like -mailcheck and/or -nomailcheck to override this pref.   This pref can be dangerous/annoying for notebook users who may fire up SM in places where they can't/don't want to do mail checking, so the ability to make different SM icons to control this behavior would be good.  (Personally, I think there's a need for mailnews to somehow become location aware to change behaviors, but that is way out of scope of this bug!)


NOTE 1:  I found that I could not make server setting changes.  I had to use about:config to change mail.server.server[3|4].login_at_startup, and ...check_new_mail did not even exist, I had to add these.  Thought maybe my profile was pooched, but when I created a new one, when I typo'd the second pop server address in the wizard, I found I could not correct it in account settings.   Something seems to have regressed WRT mail pref changes?  Or is all this just me?  :-O

(In reply to comment #176)
> Something seems to have regressed WRT mail pref changes?
That's probably a regression (waiting for bug 439058) from bug 436630.
> TB doesn't care for this preference.

But probably it should?
Opening TB from the commandline with (e.g.) -addressbook will result in the behaviour this bug is about (although they don't show any biff state, the biff *check* won't be done!).
Attachment #328155 - Flags: review?(neil) → review+
Comment on attachment 328155 [details] [diff] [review]
(Cv1) <mailnews.js>
[Checkin: Comment 180]

well, I think there's a much stronger case for the suite caring about this pref than TB - if TB decides to do something about it, it can remove the #ifdef.
Attachment #328155 - Flags: superreview?(bienvenu) → superreview+
Keywords: checkin-needed
Whiteboard: need pref pane option, see comment #161 → [c-n: Cv1 // Leave opened] [need pref pane option, see comment #161]
Cv1:

Checking in mailnews/mailnews.js;
/cvsroot/mozilla/mailnews/mailnews.js,v  <--  mailnews.js
new revision: 3.320; previous revision: 3.319
done
Keywords: checkin-needed
Whiteboard: [c-n: Cv1 // Leave opened] [need pref pane option, see comment #161] → [need pref pane option, see comment #161]
Attachment #328155 - Attachment description: (Cv1) <mailnews.js> → (Cv1) <mailnews.js> [Checkin: Comment 180]
Comment on attachment 328155 [details] [diff] [review]
(Cv1) <mailnews.js>
[Checkin: Comment 180]

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.0.2pre) Gecko/2008071216 Thunderbird/3.0a2pre] (TBNEWREF-WIN32--trunk) (W2Ksp4)

V.Fixed, this part.
Component: MailNews: Notification → MailNews: Message Display
QA Contact: search
Stopped working for me after updating from the September 10th to 12th nightly. When starting up with a browser window only, I don't get a password prompt for my account any more. Opening another browser window doesn't prompt for the account either, only if I explicitly open the mail/news window.

This is a Gmail IMAP account without passwords saved, mail.biff.on_new_window
is set to its default "true" value. Not working with today's nightly either...
[Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20080913003128 SeaMonkey/2.0a1pre]
I've made it so imap urls run without a msg window will not put up a password prompt - that was always the way things were intended to work but there were some situations where we would put up a password prompt. The absence of a message window means that the url can run unattended. The easiest way to fix this would be to have SeaMonkey create a msgWindow to pass in to the update url.
(In reply to comment #0)
> We need to be able to update the mail icon when there is new mail, without
> having to appear start the messenger application. All the accounts which have
> biff turned on and have passwords already available should be enriched with this
> feature.
This bug is fixed as advertised... if you want it to prompt for passwords, please file a follow-up bug.
Too bad, the presumed feature was actually a bug and unfortunately got fixed then... Consequently, as designed here, the new pref doesn't appear to have
any meaning for accounts for which no password is stored, if I see this right.

I have filed bug 455252 now as a follow up since I really liked that interim behavior, and it seems that comment #164 goes into a similar direction.
Blocks: 455252
(In reply to comment #175)
> (In reply to comment #173)
> > Leaving bug open for related pref pane work (see comment #161).
> 
> I would suggest to resolve this one and file a follow-up bug.

So, Karsten, Neil, what do you think?

(In reply to comment #176)
> Since I see no new bug for UI and no commentary here about a new bug, I guess
> I'll just dive right in.  :)  Seems to me that a good place to add this might
> be  Pref > Appearance :
> When SeaMonkey starts up open
>  [x] Browser
>  [ ] Mail & Newsgroups
>  [x] Mail checking (no window)
>  [ ] Composer
>  [ ] Address Book
>  [ ] Chatzilla
> 
> If M & N is selected, the checking option could be grayed out, I suppose.

I think it doesn't really fit well into the above list because it would be the only non-window option. I suggest adding a simple checkbox to the existing list under Mail & Newsgroups (General Settings groupbox).
Could we mark this bug fixed and file a separate bug or multiple of them for the open items? This has 186 comments and isn't really suited for really reading into what's up, esp. as what the summary states is actually fixed now.
Blocks: 450263
QA Contact: search → message-display
This bug is open but targeted for seamonkey2.0a1, which has been released a long time ago. Please set the target milestone to an appropriate value, "---" if it has no specific target.
Depends on: 509163
Shouldn't this actually be closed? Seamonkey 2 gets the new mail without opening the mail window, and the final version went out more than one month ago.
I guess so. UI has been added in bug 450263 and any other issues should probably go to new bugs. Marking fixed since I doubt the original reporter will do and the usual suspects ignored the prompts in comment 186 and comment 187.
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: