36025 - Need to support play sound when message arrives preference

Status: VERIFIED FIXED

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

Description

[scottputterman]

We need to have the ability to play a sound when biff goes off.

Comment 1

[scottputterman]

marking future.

Comment 2

[gayatrib]

nominating for beta3 and marking it P1. This is very similar to biff 
notification in status bar. And should be doable in nsbeta3 framework.

Comment 3

[gayatrib]

Sorry this comment was for the wrong bug. Though this bug I would also nominate 
for beta3, as it needs to be in place to make enabling sound notification work.

This is related to bug 36751.

Comment 4

[scottputterman]

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

Comment 5

[gayatrib]

Removing nsbeta3 keyword and making this nsbeta3-. Realized 36751 was a feature 
that did not make it into nsbeta2 and that is a dup of this bug.

Comment 6

[scottputterman]

nominating for mail3

Comment 7

[scottputterman]

marking nsbeta1+ and reassigning to racham.

Comment 8

[scottputterman]

moving to mozilla0.8 milestone.

Comment 9

[scottputterman]

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

Comment 10

[Peter Lairo]

this would be a very useful feature, since most people will have their mail app
behind the prog their actually working in, or it will be minimized. A sound
would be an excellent que the mail has arrived.

This would be in parallel to having a windows taskbar icon (next to clock) that
would give visual and audio alert of new mail (bug#?). Thank You.

Comment 11

[(not reading, please use [e-mail] instead)]

> This would be in parallel to having a windows taskbar icon (next to clock) 
> that would give visual and audio alert of new mail (bug#?). 

If I understand you, that is what we refer to as NSNotify. #11056

adding ryan to the cc list.  he's going to take a crack at this.


I think that's 

Comment 12

[(not reading, please use [e-mail] instead)]

taking from racham.  ryan is working on the front end, and he and I already have
the back end working.

Comment 13

[(not reading, please use [e-mail] instead)]

adding racham back to the cc list.

ryan, do you want to attach a screen shot of what you've got so far?

Comment 14

[Ryan Cassin]

Attachment: Screen shot of prefs panel (front end)

Comment 15

[(not reading, please use [e-mail] instead)]

patch for the back end coming...

Comment 16

[(not reading, please use [e-mail] instead)]

Attachment: back end part of this fix. bienvenu, sr=?

Comment 17

[(not reading, please use [e-mail] instead)]

here's a patch for back end and simple front end ui.

ryan is working on the more complicated pref ui, but it isn't ready yet.

this patch will allow you to enable and disable the sound when you get new mail.

the other prefs still work, you just don't have UI for them yet.

Comment 18

[(not reading, please use [e-mail] instead)]

Attachment: be and simple fe fix. fe code from [e-mail]

Comment 19

[David :Bienvenu]

this would be way cool.  I just want to make sure that this doesn't play a sound
on every biff that finds new mail - I think it should only play a noise if the
biff flag has changed to new mail. In other words, if I'm sitting near my
computer but not reading mail, it shouldn't go off every time new mail comes in.
It should only play a sound if I've done something with mail since the last time
I got new mail. Does this make sense? Does the code attached do that?

Comment 20

[(not reading, please use [e-mail] instead)]

your comment makes sense.

PerformStatusBarBiff() is called from OnItemPropertyFlagChanged() and only when
the new value != the old value.

put simply, once you are in the "new mail" state, additional new mail will not
keep playing the sound.

Comment 21

[David :Bienvenu]

excellent, then, sr=bienvenu

Comment 22

[(not reading, please use [e-mail] instead)]

fix checked in.

I'll go open a new bug on the extended UI that ryan is currently working on.

Comment 23

[Blake Ross]

Does this really belong in nsStatusBarBiffManager::PerformStatusBarBiff?

Comment 24

[(not reading, please use [e-mail] instead)]

where do you think it belongs?

Comment 25

[Blake Ross]

I don't know.  Something just seems wrong when we're playing a sound in 
PerformStatusBarBiff().

Comment 26

[(not reading, please use [e-mail] instead)]

blake, see my comment on "2001-01-05 18:36"

perhaps that will help you understand why I did what I did.

Comment 27

[Blake Ross]

I know. and I know this is the right place to do it.  But we're still playing a 
sound in PerformStatusBarBiff() of class nsStatusBarBiffManager, and sounds 
have nothing to do with the statusbar.

Whatever.

Comment 28

[scottputterman]

actually, the idea behind that design was that there could be different biff
services that could register themselves and be notified when biff went off. So
the hope was to have a statusbar one (really the taskbar), a play sound one, and
then a notification area one.  3 different classes for 3 different things.  I
don't know if that design would hold up, but that was the idea.

Comment 29

[(not reading, please use [e-mail] instead)]

ah, so you are saying we'd have another folder listener, similar to
nsStatusBarBiffManager, say nsSoundBiffManager, that would also check on
OnItemPropertyFlagChanged() if the biff state changed to new mail?

I don't think we should have more listeners.  We should have just one listener,
and have it call all the biff handlers.

We should have one folder listener for biff, say nsBiffManager.  We'll create a
nsIBiffHandler interface that has a single doBiff() method.

nsBiffManager would be based on nsStatusBarBiffManager.cpp, but the code to
update the UI would be moved out into nsStatusBarBiffHandler.

nsPlaySoundBiffHandler, nsStatusBarBiffHandler, (etc) would implement the
nsIBiffHandler interface and register themselves as members of the
"biff-handler" category.

on new mail, nsBiffManager would enumerate through all the services that
register themselves as members of a "biff-handler" category, QI them to
nsIBiffHandler, and call DoBiff().

to add future biff handlers, like a notification one, someone would just have to
drop in a component that had a service that implemented the nsIBiffHandler
interface that registered with the "biff-handler" interface.

comments?

Comment 30

[scottputterman]

that would be great. The main point being that all of the possible things that
would want to do something when the global biff state has changed wouldn't all
be in one class.

Comment 31

[Blake Ross]

Yeah, sounds good to me.  cc me if you file this separately.

Comment 32

[(not reading, please use [e-mail] instead)]

see bug #64947 that tracks that the way we should do this.

Comment 33

[Peter Lairo]

The feature works - woohoo

Unfortunately, the default Mozilla Mail sound (under WinNT) is really cheesy. I
checked in the control panel - sound settings, but could not find where this
sound is being set (it's not in the control panel settings).

Where is the setting that decides which sound is played?

Maby the answer should be written is the prefs setting in Mozilla.

Comment 34

[fenella]

Qa assigned to Sheela

Comment 35

[Sheela Ravindran]

Verified 
using buildid:2001021406 on mac and linux
buildid:2001021506 on windows