Closed Bug 191614 Opened 22 years ago Closed 15 years ago

Custom popup supression sound does not play. Plays default sound instead.

Categories

(SeaMonkey :: UI Design, defect)

Product:
SeaMonkey
Component:
UI Design
Type:
defect
Priority:
Not set
Severity:
minor

Tracking

(Not tracked)

Status:
RESOLVED EXPIRED

People

(Reporter: jkonecny, Assigned: jag+mozilla)

References

(
URL
)

Details

User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3b) Gecko/20030131 Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3b) Gecko/20030131 I set the popup suppression sound to a chimes.wav that is included with windows. When I visit batteries.com (who always bomards you with a popup), ding.wav plays. Ding.wav is the windows default sound. Reproducible: Always Steps to Reproduce: 1. Take note of you windows default sound. 2. Select a different wav and use it for popup suppression. 3. Visit a site with a popup. Actual Results: The windows default sound played. Expected Results: Used the wav I selected
WFM on 20030130...
WFM too, using a current CVS based trunk build, WinXP-Sp1.
Is there something I can check out for this problem? Some setting in the prefs or something...? The sound is set to a known working wav file. Sound works fine for every other application.
yes, where is the pref for sound selection/supression?
I just tried creating a new profile and it still didn't work.
I found out: It works on Windows 2000 / XP, but it does NOT work on Windows 9x/ME Systems.
Could be true... It works on my NT system but not my w98 system.
The same problem for Mozilla 1.4a on Linux (SuSE 8.1, KDE 3.0.4) - PC speaker beeps instead. This is probably the same as bug 198521.
*** Bug 207008 has been marked as a duplicate of this bug. ***
still broken in RC2.
*** Bug 211792 has been marked as a duplicate of this bug. ***
*** Bug 211248 has been marked as a duplicate of this bug. ***
*** Bug 198521 has been marked as a duplicate of this bug. ***
This feature was added in 1.3, and judging from comments in other bugs and this one, this feature has worked only in Win 2000 and XP. It is not working on Win 9x/ME, Linux, or Mac OS X. Steps to reproduce: Go to Edit>Preferences>Privacy & Security>Popup Windows Under "When a popup window has been blocked" click "Play A Sound": Click on "select", and select any sound file other than the default. Note that when you click on Preview, the default sound is played instead of the sound from the file you selected. Also, with the preference enabled, visit a site with popups and note that the default sound is played instead of the one you selected. Changed: status to New, OS to all, severity to minor. Added keyword and modified summary. Need to find a more appropriate assignee.
Severity: normal → minor
Status: UNCONFIRMED → NEW
Component: Browser-General → XP Apps
Ever confirmed: true
Keywords: clean-report
OS: Windows 98 → All
Summary: Popup suppression sound does not play → Custom popup supression sound does not play. Plays default sound instead.
Reassignment
Assignee: asa → jaggernaut
QA Contact: asa → paw
I have the same problem on linux : when i browse for a sound file it write a thing like /usr/sounds.....xxx.wav, but if i correct manually to file:///usr/sounds/...xx.wav it works fine... so to be checked under windows c:\folder\file.wav may be corrected to file://c:\folder\file.wav
Still does not WFM with the file:// prefix.
C:\Program Files\Yahoo!\Messenger\Media\pow.wav works for me so there is no need to use exotic stuff like this: file:///c:/folder/file.wav should work... Select a wav file and click on the Preview button, does that work for you?
Not for me Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5) Gecko/20030916
I'll bet comment #18 is using winnt, win2k or winxp?
Similar problem with new mail notification as <a href="http://bugzilla.mozilla.org/show_bug.cgi?id=191614#c8">comment #8</a>. PC Speaker beeps instead. Using the file:// prefix as suggested in <a href="http://bugzilla.mozilla.org/show_bug.cgi?id=191614#c16">comment #16</a>, was able to get <b>some</b> .WAVs to play, <b>others refused to play</b>. WAV playback from Mozilla also alters pitch of wav file when compared to XMMS output under Gentoo Linux 1.4, Kernel is 2.4.20. Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030913
*** Bug 233347 has been marked as a duplicate of this bug. ***
Hope this helps: When I select a sound "E:\MyData\Mozilla\glassbrk.wav" in "popup window blocking notigication" settings and click "Preview", Mozilla tries to access the registry key: "HKCU\AppEvents\Schemes\Apps\.Default\E:\MyData\Mozilla\glassbrk.wav\.Current\(Default)" The mistake in the code should be obvious: winmm.dll: int PlaySound(char* lpszName, int hModule, int dwFlags) [...] dwFlags: Zero or more of the following flags specifying what lpszName refers to and how to play the sound: #define SND_ALIAS 0x10000 // lpszName is a string identifying the name of the system event sound to play. #define SND_FILENAME 0x20000 // lpszName is a string identifying the filename of the .wav file to play. Obviously SND_ALIAS flag is used, while the correct one would be SND_FILENAME.
Most likely, the confusion is caused here: http://lxr.mozilla.org/mozilla/source/extensions/cookie/resources/content/pref-popups.xul#185 The sound "URL" is passed to the PlaySystemSound function, while it expects the event name (note SND_ALIAS flag -- http://lxr.mozilla.org/mozilla/source/widget/src/windows/nsSound.cpp#202 Also see pieces of code surrounding the first link above... pretty interesting.
Yeah, I think that does help. previewSound() calls playSystemSound when the value in the field does not start with "file://": http://lxr.mozilla.org/mozilla/source/extensions/cookie/resources/content/pref-popups.xul#185 playSystemSound uses SND_ALIAS: http://lxr.mozilla.org/mozilla/source/widget/src/windows/nsSound.cpp#202 My suspicion is that we're passing in the logical path of "E:\MyData\Mozilla\glassbrk.wav" instead of a file: URI. That also would be why the actual suppression sound doesn't play properly. See onPopupBlocked(): http://lxr.mozilla.org/mozilla/source/xpfe/browser/resources/content/navigator.js#2141 If this is indeed the case, we need to convert this to a proper URI either a) on blur of the field; or b) in both of these functions before checking for "file://".
Heh. Same links and everything.
Problem is improved w/ version 1.6 build 2004031714. Pitch problem (as I commented above) is corrected, can play .wav file without the file:// prefix.
Not confirmed. 2004031708/win98se, problem still persists.
*** Bug 249352 has been marked as a duplicate of this bug. ***
Hardware: PC → All
Product: Core → Mozilla Application Suite
MASS-CHANGE: This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
Status: NEW → UNCONFIRMED
MASS-CHANGE: This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago. Because of this, we're resolving the bug as EXPIRED. If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component. Query tag for this change: EXPIRED-20100420
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → EXPIRED
You need to log in before you can comment on or make changes to this bug.