This is a feature tracking bug for showing mail notification in the Windows system tray, next to the clock, as we did in 4.x. Dunno if we'll get to this, but we should certainly document our decision.

Marking M20. Personally I think this would be cool. But I don't know if we will have the support.

reassigning to gayatrib

adding helpwanted keyword and marking future.

nominating for mail3

*** Bug 61459 has been marked as a duplicate of this bug. ***

*** Bug 61459 has been marked as a duplicate of this bug. ***

*** Bug 61211 has been marked as a duplicate of this bug. ***

marking nsbeta1+

moving to mozilla0.8 milestone.

If this requires Mozilla to always be running, bug 50424 should be fixed before the patch for this bug goes in. Currently, you can't double-click a desktop shortcut to mozilla.exe (with no command-line parameters) to open a new browser window if any Mozilla app is already running.

i don't think this depends on bug 50424. All we need is a toolbar icon that periodically checks for mail and when doubleclicked loads mozilla WITH the -mail parameter. Since we are launching WITH a parameter (-mail), the other bug doesn't affect this feature. Even if it does, the confusion over the other bug should not prevent from starting work on this useful feature. BTW, nsnotify for NC4.x does NOT work with imap servers. This should not be the case with the Mozilla notifier.

reassigning to racham.

adding seth and hurricane to the list since they'll know when the code is all done.

updating summary. this is NSNotify. there are bugs for GNOME / KDE integration, too. (they are assigned to me.) when we do NSNotify for 6.x, we'll need to do it in a XP way.

actually this bug wasn't meant to be nsnotify. This bug was meant to be for putting something in the Windows tray when biff goes off from within the application. NSNotify was a separate app that did the same thing. Getting it to work from within the app is a good first step.

fixing summary. thanks for the info putterman. #11056 is the NSNotify bug.

*** Bug 64609 has been marked as a duplicate of this bug. ***

Before someone pointed out that bug 64609 was a dupe of this, I attached a couple of sample files that show how to add an icon to the tray. This was in case someone doesn't know how to do it, and didn't feel like digging through the old NSNotify code. The tray icon shouldn't be too difficult to add to, say, nsWindow.

*** Bug 64609 has been marked as a duplicate of this bug. ***

Mail notification... Very important. I'm suprised this wasn't in the mail prog from the beginning. NS 4.x had it. Outlook/Outlook Express has it... Most decent mail progs do. I was so confused when I discovered that I wasn't getting a wav file when my mail arrived.

moving to mozilla0.9

Bhuvan and I talked yesterday about where to put the platform-dependent code to handle this. My proposal is to add the following methods to nsIAppShellService (see http://lxr.mozilla.org/seamonkey/source/xpfe/appshell/public/nsIAppShellService.idl): void setTrayIcon( in string id, in string iconURL, in wstring toolTipText ); void removeTrayIcon( in string id ); "id" is an arbitrary, unique identifier for the "tray icon" (note that this term is kind of Windows-centric; a platform-independent term would be better). "iconURL" is an pseudo "chrome URL" that identifies (in a platform-independent way) the native icon resource to use. The format and mapping to a platform resource is the same as for window icons (see bug 57576). For example, this might be, for a mail alert icon, something like: resource:///chrome/icons/mail/mailAlert "toolTipText" is, well, the tool tip text. Probably should be called something more generic like "helpText" because the tool tip is just the Windows implementation. This might be ignored on other platforms. You can call setTrayIcon again to change the icon or help text. Use removeIcon to remove it. These methods would cause the icon to be added/removed. The only other piece is the code that notifies you when the user interacts with that tray icon. I think we only need to handle double-clicking (dealing with drop-down menus in an xp way is a pain) and a whole new interface for doing the notification isn't necessary. When the user double-clicks the icon (or whatever the equivalent is on other platforms), we will fire off an nsIObserverService notification. The topic will be the "id." I think the same 2 methods will be added to nsINativeAppSupport so that we can easily provide platform-specific implementation. The methods will need to be in nsIAppShellService, also, because naINativeAppSupport isn't scriptable (because it has to come to life before xpcom to handle the splash screen).

QA-assign to Sheela

Law, that sounds good. It should handle the basic needs for the notification. If we want to add the right-click menu, we could do it on a platform-specific basis.

marking nsbeta1- and moving to future milestone.

*** Bug 79090 has been marked as a duplicate of this bug. ***

outlook has it, yes but only when outlook is started and using a whole slot of the taskbar, then it starts up a trayicon when mail arrives... mozilla should be able to stay in the trayicon like the old netscape mail notifier and tell the user when a new mail arrives by flashing or an animated icon! but it should be mozilla down there and not any small prog like netscape mail notifier - a user could be able to start a navigater window through double clicking or something, that would be nice

Law, I love your of adding to the nsIAppShellService & nsINativeAppSupport interface. Makes it easy to add tray icons. Dean Dessman has provide almost all the Win32 code in bug 64609. Looks like all that needs to be done is wrap that code into the Win32 implementation, hook up the IDL's and add the nsIObserver. Is anyone already working on this? It's marked Future and helpwanted. I don't want to waste my time looking further if there is already a conservative effort to do something similar in another bug. It seem to be blocking a lot of other bugs like biff notification, preloader, and AIM could use it just to mention a few.

Okay, this patch lays the groundwork intefaces that need to be implemented. Please let me know what you think. I think it'll work nicely XP in the future without having us to implement on every platform right now. TODO: 1) Incorporate the patch from bug 64609 for calling the Windows API 2) Rip off the code in nsWindow::SetIcon for getting a chrome:// or res:// icon to create an HICON. Is there another way to do this? 3) Add MSG_SYSTRAY to WndProc. What Hwnd should I use? 4) Then we will probably need to convert the event to a "netscape" type GUI mouse input event. 5) Grab the nsIOberverService to send out the event notification to all registered listeners. ** 6) Implement on Mac, Linux, and other platforms. cc:ing Joe and Syd on this as they may want something like this for AIM. I know there's a Bugscape bug similar to this but doing it XP is better anyway. Clearing milestone to trigger re-evaluation for post beta1.

Patch #2 actually has some code in it. Not quite sure if it works correct, but it compiles. I'm jumping through some hoops to get the hWnd of the hidden window so hopefuly I didn't make too many mistakes. It addresses my issues #1-3. Thanks Dean for some of your code. Left to do: 1) Add code to widget's windows/nsWindow.cpp to handle my new callback message (WM_SYSTRAY_MSG). 2) Convert that to a mouse click input event 3) Handle Observer callbck. This may be a little tricky if it's in nsWindow 4) Need to figure out how to develop a testcase to try this out!!! 5) Cleanup. Possibly add prefs. Alas, I must tend to my mozilla0.9.1 bugs.....

The code you've attached looks OK, for the most part (I didn't look it over too closely, though). As it happens, the fix for bug 53952 adds a new "hidden window" of sorts, and I was thinking that it would be a better place to put the handling of the systray messages (its window procedure is right in nsNativeAppSupportWin.cpp). I think that might make the code cleaner. I've also (as part of work on bug 75599) replaced nsINativeAppSupport.h with a .idl file (which your patch conflicts with). I also agree that we should try to reuse the same "icon url"-to-filename mapping code as is currently in nsWindow::SetIcon. Maybe add some generic "convert" method to nsINativeAppSupport that takes a pseudo-icon url as input and returns the appropriate native file path. I've got the same mozilla0.9.1 bug list problem, so I don't have time to work on this right now. It might be better to tackle this after some of the code for bugs 75599 and 53952 lands.

Oh wow...yes..I wanted to use the hidden window for getting the sys tray callback but I didn't relaze it was in the same file. Is it the "splash screen" that's the hidden window? I need to figure out how to get the hWnd of the hidden window in nsNativeAppSupportWin.cpp.

No, this new window isn't the same as the splash screen...best is to have a look at the patch attached to bug 53952, I think. I thought the "hidden window" went away (except on Mac). Or is it just not a xul window now, or something?

Ahh...yes..I see what you mean. Marking dependancy (please change if you feel otherwise). That would be GREAT! Much better to leave all this implementation in one file anyway. This may make it for mozilla 1.0.

peter: this may be of service: http://lxr/commercial/source/AIMGlue/src/nsCUIHelper.cpp#413

Hidden window mentioned, must cc: danm! /be

Aaaaaaaaaaaa! Curse me for not destroying nsCUIHelper yet. It shouldn't be used as a guideline for new code. HiddenWindow has been nearly completely expunged from the Mozilla codebase, though the out-of-date Netscape branch still revels in it. We're trying very hard to completely remove it (except on the Mac, where it's insurmountably useful) because (a) it's a performance hit and (b) people keep using it for stuff. Please don't use or rely on HiddenWindow for anything. We've been making progress toward its removal. New uses will only make my dream of wrapping my hands around its scrawny evil neck and throttling that much harder to fulfill.

actually, I think that a os-dependant notification system needs to be in a seperate interface, apart from nsINativeAppSupport.. nsINativeAppSupport is already starting to handle a bunch of mismatched components as it is. Let's basically implement a single interface which has three implementations, each of which does it's own handling of creating the native taskbar icons, etc. I'll call it nsISystemNotification for argument's sake. In the case of windows, where the taskbar icons need a native HWND to hang off of, let the Win32 nsSystemNotification implementation have it's own private (hidden) window to hang it's icons off of. Linux and Mac might not require such a hidden window to do notifications..

That sounds like a good idea to me.

Here is a little thing that is often forgotten but can be useful (when explorer crashes): Taskbar Creation Notification Microsoft® Internet Explorer 4.0 will notify applications that the taskbar has been created. When the taskbar is created, it will register a message with the "TaskbarCreated" string and then broadcast this message to all top-level windows. When your taskbar application receives this message, it should assume that any taskbar icons it added have been removed and add them again. The following example shows a very simplified method for handling this case. LRESULT CALLBACK WndProc(HWND hWnd, UINT uMessage, WPARAM wParam, LPARAM lParam) { static UINT s_uTaskbarRestart; switch(uMessage) { case WM_CREATE: s_uTaskbarRestart = RegisterWindowMessage(TEXT("TaskbarCreated")); break; default: if(uMessage == s_uTaskbarRestart) AddTaskbarIcons(); break; } return DefWindowProc(hWnd, uMessage, wParam, lParam); }

*** Bug 87937 has been marked as a duplicate of this bug. ***

*** Bug 87124 has been marked as a duplicate of this bug. ***

*** Bug 89823 has been marked as a duplicate of this bug. ***

Marking 4xp per the original comment and the latest dup.

i wanna tell that you already did a notify icon for the mozilla turbo start now, so the argmuent (rather old on this page) that notify icons are bad because they are only for windows doesn't work anymore. just get a second trayicon up when a email arrives, the trayicon could be animated and playing a sound once (the user should be able to choose wich one to play) and could even put a baloon up (yellow field like the tooltip but it is larger and will be used in windowsxp much by microsoft) how about that?

Instead of having two icons (turbo & mail notify) for one program (Mozilla), it would be better to integrate the functionality into one tray-icon. It shouldn't be too difficult to have a meaningful logic so these two can coexist in one tray-icon (e.g., context menu: (A) disable turbo mode, (B) disable mail notify, (C) disable turbo mode & mail notify. If a window is open and user selects (A) or (C), the window stays open but without turbo mode). I have filed bug 90466 to track this "merger" (please vote and CC yourself if interested).

that's a really good idea. voted for it and cc'ed myself ;)

*** Bug 93424 has been marked as a duplicate of this bug. ***

mscott (mail pseudo-manager now iirc), is this work going to be targetted at some point? It continues to be one of the top feedback requests for mail, from 6.0, 6.1pr1 and 6.1.

*** Bug 98869 has been marked as a duplicate of this bug. ***

Nahor: after reading your comment several months ago, I filed bug 100846 for turbo to use the TaskbarCreated notification, not remembering where I had heard about it or what it was called. Now I know :)

reassigning to sspitzer

*** Bug 105402 has been marked as a duplicate of this bug. ***

*** Bug 104295 has been marked as a duplicate of this bug. ***

*** Bug 83652 has been marked as a duplicate of this bug. ***

What is still necessary in order to finish this?

1. Show envelope on Windows task bar when mail is waiting. 2. Fix bug 84705. 3. Perhaps add a couple words to the preference dialog to say "Play default Windows mail sound when new mail arrives."

Shouldn't this be made dependant on bug 84705 then?

That isn't enough information. Who is currently working on this (if anyone)? Is the patch obsolete - how much of what is left to do do we have? 1. Show envelope on Windows task bar when mail is waiting. Have you made the icon? Have you made the code to show the icon? Which parts of this aren't complete? 2. Fix bug 84705. 3. Perhaps add a couple words to the preference dialog to say "Play default..." Does the sound already play? Is the UI all you need? You talked a lot about the notification icon for the turbo feature. How does that play into this? I'm not going to even think about working on this bug until I get some real information about what needs to be done. I already have 4 bugs I'm working on. If I got the information I needed, then I feel I could do parts 1 and 3 rather quickly.

Sorry - forgot to mention - On part 3, I wouldn't do the UI, but if you need the default mail message played, then I could do that.

It looks like mscott will get to this as part of a replacement to nsnotify. I'll reassign when I know more.

The code for showing an icon is written cause the Turbo-icon is the same thing... We though about the turbo icon chaning when new mail arrives to some kind of animated thing so that the user can see that there happened something... I think mozilla doesn't play a sound when mail arrives, the ui has to be made for soundselection and the coding to make mozilla play a sound... Currently if you double-click the turbo icon a new browser window opens... This behavior has to be changed in case there has a mail arrived... Then it should open the inbox... The icon should go back to normal if you read the mail.. but this depends on bug 84705 ...

1. Show envelope on Windows task bar when mail is waiting. Have you made the icon? Have you made the code to show the icon? Which parts of this aren't complete? Who? Me? I am just an incompetent user/tester. Steal the icon from Netscape 4. 2. Fix bug 84705. I suspect this bug will mess up toolbar icon behavior also. Does the sound already play? Is the UI all you need? YES, the default Windows sound already plays. That was fixed a long time ago - See comment 39 of Bug 64475.

There are two ways this can be worked. 1. Have the Netscape 6 Icon in the tray change to a mail flag when mail has arrived. 2. A second Icon appears saying mail has arrived and when its clicked on it brings you right into the mail. I have another suggestion too for when mail arrives besides just playing a sound. For those of you who use Norton Antivirus 2002 you will know what im talking about. When new virus deffitions are downloaded a little box pops up right above the tray saying 'virus deffintions updated' then it goes away 2 seconds later. Would it be hard to incorporate something like this after we solve the original problem?

Many comments presuppose use of turbo mode. I think many people do not use it, so simply changing the icon in the tray from Moz/NS6 to show mail will not work. If icon is added for non-turbo people, and then it disappears once mail is read, OK. Scott's latter paragraph seems to be a separate RFE that I don't think should become part of this bug. I hate those little popups, anyway. I like sound.

There's a standard cross-platform notification system built into widget (nsIWidget::GetAttention). No need to worry about specifics like icons. Just use the toolkit (and modify it if it isn't everything you need, of course).

i would vote for the dialog ... but it has to be to the upper right on the screen and without a windowborder... it should slide in with a nice icon saying You have [number] new mail message(s) and when you click on it it should open the messenger... And it should disappear automatically after a time setable in the preferences... that would be kind of cool... why not making a option for sound yes / no | dialog yes / no and trayicon yes / no that would be the best solution i think

Harald, 100% agree, this would be a really nice set of features. Personally, I don't like any dialog boxes - but it could also be possible to display the number of new mails in the tray icon. E.g. if you copy a file with the Windows Commander (a file manager for windows) and minimize it to the systray, it still shows the percent-progress in the tray icon - and you can read this quite well. And if somebody really has more than 100 new mails at a time an the space becomes to tight - well, display something else. :) Axel (...just adding a comment)

Ok don't want to add more spam. But wanted some clarification. By dialog are we talking about something like yahoo messenger does. When someone comes online or sends you a message when you don't have a window open for them, it floats a small "tooltip" above the tray icon and contains text telling you what is going on. I'll see if I can post a screenshot. This would be very nice.

when i talk about a dialog... i think of it like microsoft messenger.. when someone is getting online or sending you a message a window slides in from into the right lower edge of your screen with a nice background and an icon saying "blah is telling you something"... i'd like that very much... like described above... of course everyone would like it in a different way so this has to be very flexible in the preferences..

Exactly like the messager. It isn't really a dialog, just a tool-tip maybe 1x2 in the corner of the screen then it fades away on its own. Doesn't really get in the way at all.

I logged bug 115348 to track generalizing the System Tray Support so that mail can access it.

I personally would like just a sound, and an icon. When you move your mouse over the icon, a tooltip would come up showing you how many new mails you have. I think the icon should be a mailbox with a flag up :-) Three suggestions: 1) Yahoo tooltip type thing 2) Sound 3) Icon Why not do all 3 and make each one a preference?

Just so programmers can see it, this is what yahoo shows when someone comes offline or sends you a message when no windows exist. looks like this but says the message and truncates it if its too long. Censored name from screenshot to protect the innocent :)

reassigning to mscott. This will go in as part of nsnotify.

*** Bug 117985 has been marked as a duplicate of this bug. ***

This attachment provides a proposed interface with a full set of methods to manipulate "system notification widgets" (i.e., "systray icons" on Windows). This interface does the job for the Navigator QuickLaunch systray icon needs. Need verification that this will work for mailnews, etc. (and need to implement it, of course :-).

my suggestions: - add local addObserver/removeObserver and do event notifications that way.. possibly even use another well-known interface like nsIEvent? That way the entire system doesn't have to be notified about events which have only one or two consumers - keep context menus (or any other UI) out of this interface - maybe put in a seperate nsISystemNotificationMenu interface, or at the very minimum allow context menus to be defined in XUL and implemented as xul popups. UI should always be manipulated with DOM interfaces. - make the icon IDs urls to icons or some sort of CSS class... I'm almost wondering if you might want to load a small XUL document which represents any content that might be related to this icon.. this would also give you a JS context to work in. cc'ing hyatt for ideas.

Thanks for the feedback, Alec. My replies on each point are below... re: local nsIObserver vs. nsIObserverService Having a per-"widget" or per-menuitem observer is nicer. Would it be good enough to add an "in nsIObserver" argument to createWidget? That would support one observer per widget (and no way to change the observer) but that's probably OK. re: keeping UI out of the interface I'm not sure I see the benefit of separating out the menu item stuff. I don't think any clients are ever going to set up systray icons (or equivalent) without specifying what happens when the user interacts with them. So every client is going to have to deal with the nsISystemNotificationMenu interface anyway. A new interface to bundle up a few simple attributes seems like over-COMifcation, perhaps. Defining the context menus in XUL is problematic. We don't "own" the systray icon on windows and I'm not sure it's possible to do that. Thus, we can't see the low-level mouse/menu events that trigger display of the context menu. We *could* extract the necessary information from the xul document to construct the native context menu, but that just makes things more difficult for the clients, I suspect, with no increased cabability. re: Icon ids == urls Yes, that's what I meant. If you look at the "icon ID strings" that nsWidget::SetIcon supports, they are resource URLs that are mapped to platform-specific files using some per-platform convention. Window icons are "skinnable" via css but I'm not sure how to accomplish that in this case (in the case of window icons, the <window> object's style attributes control the icon).

> Defining the context menus in XUL is problematic. We don't "own" the systray > icon on windows and I'm not sure it's possible to do that. Thus, we can't see > the low-level mouse/menu events that trigger display of the context menu. I don't get what you mean here, Bill. All we need to do in Windows is capture the mouse click on the tray icon, which is simple to do. After that we can do anything we want to, such as displaying a XUL window / menu.

yes, what dean said. The reason is this: First you'll add these menu-item APIs. then people will ask for icons in their menus. Then people will ask for checkboxes.. then people will want to disable them, or make some of them bold. then someone will want to put a logo on top of their menu, then someone will want a dialog to pop up instead of a menu. then someone will want /right/ clicking to pop up a menu, but /left/ clicking to open a window. The list goes on and on. We can't keep adding APIs, it's just not a scalable solution, not to mention you'll keep adding proprietary APIs instead of standard DOM APIs which people know and love. (I see literally ALL of the above in the taskbar icons on MY desktop...) One thought is to have one main, hidden "window" that loads a xul document, and have taskbar consumers overlay their own ui into that document.. that might save the overhead of having a seperate window per icon.

Anything is possible, I suppose. Using xul popups seem hard because they have to have a parent <window> and we don't have one here. I was envisioning putting the <window> in the system tray and getting the popup that way. That's the thing that's (probably) impossible. I did find an article where somebody had wired up a 16x16 window and some code to bit-blt the window to an HICON and then send that icon to the system tray every second. So he used that to allow you to put anything you wanted in the system tray. Quite clever, but overkill if you just want a simple menu. And that just managed the visible window content, no event handling. I suppose we could have some sort of hidden window that owned the menu and route the notifications from the systray icon to that window (which would then show the popup). The hidden xul window we do have has been the source of unending aggravation (ask danm) and it is *really* hidden (no popup menus except native Mac ones). I'm not anxious to sign up to support another one of those. Bottom line is: I don't have time to implement a xul-based menu system for this in the time frame we need it. How about a compromise: If there are no menu items defined for one of these "widgets", then mouse events (the limited ones Windows sends us; on Win32) can be passed to the observer. That way, an ambituous observer of this interface could implement their menu the way you suggest. That's what we'll tell the people who start asking for animated menu icons, etc. And clients who just want a simple menu can easily get one.

mscott, this is the bug I was referring to. law, I didn't mean putting a XUl window into a 16x16 area, I meant a hidden window which was the master taskbar window

Being a former Communicator user, I miss this feature horribly. I hope this makes 1.0, for 4.x parity at least. Adding myself CC: and voting for this bug.

Bill: sounds like a good idea. There is no need for the kind of complexity required for OS-specific widgets on a windows-only feature. Besides, that color menu would clash with all the other menus in the systray.

Bug 119344, if fixed for all Windows versions, would be the last item for me to "vote" this bug (18279) fixed. Bug 84705 currently worksforme with build 2002012304. The new mail sound has worked correctly for a very long time. Task bar notification, any at all, is really enough. I don't see any need to get fancier.

Well the icons there, but shouldn't clicking on it open mail? It doesn't.

I don't see any icon in the taskbar, using the lastest build (2002012803)? I use NT. I only see the little green arrow on the mail icon on the status bar. Do I have to tweak prefs.js to see the taskbar icon?

It doesn't seem useful to implement this in XUL when it's not a crossplatform feature and there aren't a lot of resources to spend on this.

Bug 119344, though closed, says that tray icon is still not there on Win95, 98, and ME. I am using build 2002020803 with WIn98, and the icon is NOT there.

moving this bug out since this isn't what Scott's been using to track his integration work. Currently we have a tooltip and an icon.

> Currently we have a tooltip and an icon. ...which don't work in win9x (or do they by now?) Isn't this one of the most requested feature? It seems "nsbeta1-" is asking for disapointment from users.

Peter, please understand that Mozilla is overloaded with features at this moment (don't forget to count download manager in them). Surely there are important features being "futured" but what seems to be critical at this moment is to freeze the api's and fix some nasty bugs for the upcoming Mozilla 1. and MachV releases. Asking for features doesn't help the project (my opinion only and I don't think it's apropriate to discuss it here).

I just wanted to jump in with some clarification here. This bug is still open because it has had some great discussion for a cross platform way to maniuplate icons in the system tray. I actually had an other bug open which I used to implement new mail notifications in the system tray. Mail already had a windows only file containing windows specific biff integration hooks so it was trivial to add a call to ShellNotify to add the icon to this file without requiring the over head of a cross platform implementation. Unfortunately Bug #122626 is still out there (and that is nsbeta1+) which causes this icon to not show up on win98. I haven't figured out what's causing that yet. That being said, it's still beneficial to continue the discussion which is why this bug is still open. However, it's not beneficial to continue the discussion before mozilla 1.0. So this bug: nsbeta1- and not required for 1.0. biff icon not showing up for win98: 122626 and that's nsbeta1+. Hope that helps.

Windows integration for new mail notification doesn´t work with Mozilla 0.9.9 with Windows 98 SE.

if mozilla is _just_ running in the systray without having any messenger or navigator window open it doesn't check for new mail... is filed in another bug # ?

sorry for the spam but: wouldn't it be better to have one icon showing both the running turbo mode and the new mail arrival? probably that would also be a workaround for bug #122626 ... i would think of a normal icon when everythings normal and no mail is there and a little message sign over the icon if mail arrived...

adding self to cc list

Sorry if this is wrong. I'm a newbie really. I'd just like to note that to have a "system try" on Linux Mozilla needs to create a mini-xul window. This miniwindow is marked specially so that Gnome and KDE put it in the "system tray". If something similar could be done on Windows, a lot of code would be able to be shared. If Windows supports static icons only, then there could be an offscreen xul window (!) copied to an icon. This copy would happen only when there is a change in that window.

New mail notification icon never goes away till you completly close browser. Should this be a seperate bug?

johnlar: Mail notification doesn't go away because, essentially, once you open MailNews, it never closes until you completely exit Mozilla. So, if you have MailNews configured to check for new mail every "x minutes", it will continue to check for new mail even if MailNews is "closed". And, yes, that should be a new bug (I figured that it would be filed already, but I can't find it). If you happen to file that as a new bug, please also add me to the CC list.

There doesn't appear to be any biff type functionality on platforms other than win32, for Mozilla. For example, on Mac OS X, I'm running Mozilla and when new mail arrives (and I'm not in Mozilla to see the mail/news button update), no external notification tells me that new mail has arrived. Most every mail application I've come across since I've been working with OS X has some sort of biff notification in its Dock icon. I think Mozilla should as well. Obviously this bug is about integrating NS4's biff functionality into win32/Moz, what I would like to know is if a bug has already been filed to bring similar functionality to Moz or if this needs to be done?!?

Brice - a very quick search of bugzilla using 'biff dock' turned up bug 86553.

When a customers telephone call dos not go through to one of my colleagues, the switchbord people sends an e-mail, and asks him to call the customer. It is important for our company's survival, that my colleague sees the e-mails. A tiny icon in the sys-tray is not enough. Outlook places a message-box in the middle of the screen that ensures it. Moz mail can raise a message-box from the sys-tray, that is good enough, if the prefs is changed, so it is open for a hours and not a few seconds, though it ought to have a pref, where it stays open until it is click'ed on. We have to define the pref so my colleagues see the notifier after a offee-break, but then the message-bog stay's up all the pref-time and can not be click'ed away, when he sees it immediately. It is a minor problem, that moz mail has to be open - Outlook has to too. mvh... Morten Christensen

*** Bug 158852 has been marked as a duplicate of this bug. ***

Very good done guys... The mail notification system in build 20020830 is perfect. Good work. Now there's only one more problem... Mozilla has to check for mail also if the messenger isn't opened. It doesn't do that currently. Also it would be great if mozilla checked for mail while in turbo mode and opened in the system tray only... How about that?

I hope this is the proper forum for this comment ... the lack of an e-mail notification feature in Mozilla is a serious oversight. I've been using Netscape for years in our school system, but with all the press play about Mozilla I thought I'd use it instead, primarily for its LACK of that horrible AIM component, and for its ability to block popup ads. I was astounded to see that it did NOT have the e-mail notification support which was found in Communicator 4.7x. I can tell you developers, this is a "can't use it then" issue. Our school's teachers and staff would completely balk at a browser whose e-mail subsystem lacks a notifier. Of course, this means a notifier which resides in the SysTray and tells them they have mail, even though the browser is not running. Mozilla currently will notofy you of e-mail once it's started, but that's redundant. People need to know there is mail waiting, so they have a reason to start the browser. They want to be able to tell, at at glance, that they should start their browser. They shouldn't have to start the browser and find, oh well, no e-mail right now. I'll look again later. Start-stop-start-stop the browser? That's not gonna happen. So often, it's the small things which matter a great deal, and the "no NSNotify" of Mozilla is a poison pill. When this is available, let me know and I'll put Mozilla on all our desktops ... until then, no way. I'd be drawn and quartered by the staff.

Does mail notification still work if Mozilla is in quicklaunch mode? If this were the case, you'd just have to start mailnews once to get the checker code started, then the process would still be there due to quicklaunch. If this is not the case, maybe this would be a good idea. Does Outlook have a mail notification checker?

isn't this completed? in windows xp, i get new mail notifications... (note - i am running LiteStep {so non-std system tray} and the popup is in the bottom right while my systray is right middle ...not that that matters, it still comes up in the bottom right) why is bug 115348 dependant? it was added in comment 74 ... shouldn't that be blocked by this? recommending a close of this bug (assuming this fix also works on win2k and win98). adding self to cc list.

This was mail notification when Mozilla wasn't running. I doubt you get notification if Mozilla is not running.

are you referring to bug 11056? what you described does NOT match the summary, however it DOES match bug 11056's summary. ...or are you implying that when mozilla's quicklaunch agent is open, mail should be checked. again, the summary would need updating. you are correct about no notifications while mozilla is closed (obviously). i think we're falling too far into the monolithic mozilla approach; if i'm not running mozilla mail, i don't want email notifications. this seems FAR better served in a third-party application (bug 11056), which could be linked to by mozilla/moz-quicklaunch as an option. (just my $0.02)

You know what... I really don't know what this bug covers. Sometimes they are talking about a nsnotify style program, other times not. I agree bug 11056 is what I am looking for specfically though.

WTF Are Netscape/AOL on glue "nsbeta1-" "nsbeta1- This keyword will be added to bugs which the Netscape evaluation team has rejected for the next Netscape release."

"nsbeta1-" means "we don't have anyone available to work on this right now; more important things need to get done". If you don't like that, feel free to give Netscape money to hire more people. In any case, that does not affect non-Netscape developers' ability to fix the bug. Notice that "helpwanted" keyword?

Sorry I mis-understood

*** Bug 190835 has been marked as a duplicate of this bug. ***

the most straightforward solution seems a resurection of NSNOTIFY.exe It's perfectly mozilla compatible as is (needs IMAP support though). I run it in my startup folder and have changed the client to Mozilla mail. Mozilla definitely needs an email notification that has a very small resident memory footprint that can run without the browser running. Here are some dream features: auto-cancel timed email check if processor/memory usage peaks: NSNOTIFY can cause buffer errors during CD burns and can interfer with processor-intense software when it checks for new mail. If it could detect memory and processor peaks and delay it's scheduled check accordingly-- well that would be awesome. sound rotator - getting new email is exciting... hearing the same new email sound each time is rather dull... if a library of sound clips could be loaded and played randomly upon new mail preferences -- well that too would be awesome. There are tons of tweaks on this concept -- perhaps the notification software could have an option to assign sounds based on the number of new messages (i.e. "you've got 2 new mail messages")

Call me insane, but isn't the whole idea about this thing that it is supposed to be _extremely_ lightweight/stable? Features doesn't lend itself to being lightweight/stable. I think we should get it to work in the most basic way before we start adding things like ability to brew your expresso while you are waiting for your mail.

If anything in terms of timing, we might want to not make a sound more than, say, every 5 minutes.

Please take standalone notification discussions to bug 11056. For exciting new features of notification (like rotating sounds... hm), create new bugs. Thanks. There are certainly bugs with mail notification (see for instance bug 116181) but this is DONE. Right? Nobody has offered a reason why not since comment 111.

Wouldn't this dupe Bug 11056 and not be FIXED?

Please move your VOTES to bug 11056 - Implement new mail check standalone app (nsnotify)

This bug has been in for a long time now, and works on all Win9.X and Win2K/XP variants. Verified FIXED, using Seamonkey build 2004-07-28-08 on Windows XP and Win2K (but while working at Netscape, this was tested on Windows ME and Windows 98, too).