613806 - alert(), confirm(), prompt() dont play system alert sounds

Status: RESOLVED FIXED

(Toolkit :: General, defect, P3)

Description

[Biju]

Thanks for bug 59314 fix...

My windows sounds setting is to ring "bell" on alerts but after bug 59314 fix alert(), confirm(), prompt() dont ring bell

Comment 1

[Jonathan Haas]

Do we want this? I think they should behave like simple DHTML popups made with normal javascript, and these don't generate sounds by default.

Comment 2

[Andreas Jung]

To play a sound could be confusing.

Assume you have three tabs A B C opened and you currently have tab A visible.
Now C creates an alert.

Previously alerts were modal and the tab that created one was brought to the front so you heard the sound, saw the alert and the tab that created it (here: tab C).

Now that alerts aren't modal anymore you would get the sound, but tab A remains visible and you wonder why the sound was played.

Comment 3

[Matthew Tuck [:CodeMachine]]

There's some discussion on bug #598824 about what happens to show the user when an inactive tab brings up a dialog. If it was decided to have a glow effect for other tabs and to make the browser autoscroll to that tab if it's offscreen, then it would be more obvious to the user.

Comment 4

[Biju]

(In reply to comment #1)
> Do we want this?
Yes in corporate world it is needed.
Many intranet application there comes specification asking when to play what sound and what message.
In our company we have a standard flash library to achieve that.
I assume other companies will be depending on this feature, and firefox should continue providing that depending upon user OS setting. As was there before bug 59314 fix.

When at work personally I dont like sounds coming from the System, especially from a web application.

I do wish there is about:config item to disable it.

Comment 5

[Justin Dolske [:Dolske]]

Oops, I actually accidentally broke this in bug 575485. Simple fix.

But it does raise the question of if tab-modal prompts should play an sound or not -- I don't think they should. They're supposed to be part of the web page, and are explicitly not supposed to look or behave as an official system dialog. We've already made this call on other aspects of the dialogs, so I'm only un-breaking the sounds for normal prompts.

Comment 6

[Justin Dolske [:Dolske]]

Attachment: Patch v.1

Comment 7

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 492236 [details] [diff] [review]
Patch v.1

It looks to me like nsISound implementations exist on all the platforms we care about (and even qt, os/2 and beos!), and the playEventSound implementations don't throw in any of them (except for in edge cases like OOM), so I don't think the try/catch is useful except for hiding issues like these... but I suppose it's better safe than sorry at this point, so maybe just add a reportError() to the catch?

A comment mentioning the |if (xulDialog)| check's purpose (limit this to non-tabmodal prompts) would be useful too.

Comment 8

[Justin Dolske [:Dolske]]

Yeah, I'll just add a reportError for now. This is just cut'n'paste from the original patch that added this code to commonDialog.js (bug 463209). Perhaps Masayuki remember why it was done that way?

Comment 9

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

because the method might return NS_ERROR_NOT_IMPLEMENTED or something in future especially when some developers will implement new platform's widget. If the playEventSound() stops the initialization of the dialog, it make users confuse.

Comment 10

[Nikita Popov]

> To play a sound could be confusing.

> Assume you have three tabs A B C opened and you currently have tab A visible.
> Now C creates an alert.

> Previously alerts were modal and the tab that created one was brought to the
> front so you heard the sound, saw the alert and the tab that created it (here:
> tab C).

> Now that alerts aren't modal anymore you would get the sound, but tab A remains
> visible and you wonder why the sound was played.

This shouldn't be a problem. Windows does exactly the same. If some application does something I ought to know then a sound is issued and in the taskbar the program's icon starts blinking and turning orange. As the notification for dialogs in non-focused tabs will probably be very similar this is common and thus expected behavior.

Comment 11

[Justin Dolske [:Dolske]]

Pushed http://hg.mozilla.org/mozilla-central/rev/b890963a137e