Closed Bug 18729 (MailNotification) Opened 25 years ago Closed 21 years ago

[FEATURE] Windows integration for new mail notification

Categories

(SeaMonkey :: MailNews: Message Display, defect, P1)

Product:
SeaMonkey
Component:
MailNews: Message Display
Platform:
x86
Windows NT
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
Future

People

(Reporter: phil, Assigned: mscott)

References

(Blocks 1 open bug)

Details

(Keywords: helpwanted, Whiteboard: [br])

Attachments

(4 files)

laying interface groundwork
4.10 KB, patch
Details | Diff | Splinter Review
next revision (#2) actually adding some meat to the code
9.73 KB, patch
Details | Diff | Splinter Review
yahoo screenshot
5.22 KB, image/jpeg
Details
Laying some more interface groundwork
2.36 KB, text/plain
Details 
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.
Status: NEW → ASSIGNED
Target Milestone: M20
Marking M20.  Personally I think this would be cool.  But I don't know if we
will have the support.
QA Contact: lchiang → fenella
reassigning to gayatrib
Assignee: putterman → gayatrib
Blocks: biff
Status: ASSIGNED → NEW
Target Milestone: M20 → M16
Status: NEW → ASSIGNED
adding helpwanted keyword and marking future.
Keywords: helpwanted
Target Milestone: M16 → Future
nominating for mail3
Keywords: 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. ***
Keywords: nsbeta1
Priority: P3 → P1
Whiteboard: [nsbeta1+]
marking nsbeta1+
moving to mozilla0.8 milestone.
Target Milestone: Future → mozilla0.8
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.
Assignee: gayatrib → racham
Status: ASSIGNED → NEW
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.
Summary: [FEATURE] Windows integration for new mail notification → [FEATURE] Windows integration for new mail notification (4.x NSNotify)
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.
Summary: [FEATURE] Windows integration for new mail notification (4.x NSNotify) → [FEATURE] Windows integration for new mail notification
*** 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
Target Milestone: mozilla0.8 → 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
QA Contact: fenella → sheelar
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.
Keywords: nsbeta1 → nsbeta1-
Whiteboard: [nsbeta1+] → [nsbeta1+ 2/21]
Target Milestone: mozilla0.9 → Future
*** 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.
Attached patch laying interface groundwork — — Splinter Review 

    
    

    
  
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.
Target Milestone: Future → ---

    
    

    
  
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.
Depends on: 53952
Keywords: mozilla1.0

    
    

    
  
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.
Keywords: 4xp

    
    

    
  
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).

    
  
Blocks: 90466

    
    

    
  
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.
Whiteboard: [nsbeta1+ 2/21] → [nsbeta1+ 2/21][br]

    
    

    
  
*** 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
Assignee: racham → sspitzer
Keywords: nsbeta1-
Whiteboard: [nsbeta1+ 2/21][br] → [br]
Target Milestone: --- → mozilla0.9.7

    
  
Blocks: 102231

    
    

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

    
    

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

    
  
Keywords: mail3 → nsbeta1+
Target Milestone: mozilla0.9.7 → mozilla0.9.9

    
  
Blocks: 108795

    
    

    
  
*** 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.
Depends on: 115348

    
    

    
  
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?

    
    

    
  

      
      
      
      

        Attached image
          
        yahoo screenshot
        — 
      

    


  
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.
Assignee: sspitzer → mscott

    
    

    
  
*** 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.

    
  
Blocks: 11056

    
    

    
  
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.
Keywords: nsbeta1+ → nsbeta1-
Target Milestone: mozilla0.9.9 → Future

    
    

    
  
> 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.



    
  
No longer blocks: 102231

    
  
No longer blocks: 108795

    
    

    
  
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...
QA Contact: sheelar → stephend

    
    

    
  
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


    
  
Alias: MailNotification

    
    

    
  
*** 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?

    
  
Blocks: 164421

    
    

    
  
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.

    
  
Depends on: 71105

    
    

    
  
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. ***

    
  
Blocks: majorbugs

    
  
Keywords: mozilla1.0

    
    

    
  
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. 
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED

    
    

    
  
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).
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey

    
  
No longer blocks: 164421

    
  
Blocks: 158464

    
  
No longer blocks: majorbugs

    
    

    
      
  

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: