Closed Bug 613806 Opened 10 years ago Closed 10 years ago

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

Categories

(Toolkit :: General, defect, P3)

defect

Tracking

()

RESOLVED FIXED
mozilla2.0b8
Tracking Status
blocking2.0 --- -

People

(Reporter: BijuMailList, Assigned: Dolske)

References

Details

(Keywords: regression)

Attachments

(1 file)

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
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.
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.
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.
(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.
Keywords: regression
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.
Blocks: 575485
No longer blocks: 59314
Attached patch Patch v.1Splinter Review
Assignee: nobody → dolske
Attachment #492236 - Flags: review?(gavin.sharp)
Summary: alert(), confirm(), prompt() dont ring bell → alert(), confirm(), prompt() dont play system alert sounds
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.
Attachment #492236 - Flags: review?(gavin.sharp) → review+
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?
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.
> 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.
Pushed http://hg.mozilla.org/mozilla-central/rev/b890963a137e
Status: NEW → RESOLVED
blocking2.0: ? → -
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b8
See Also: → 1687380
You need to log in before you can comment on or make changes to this bug.