Typing "rheeet" into chatzilla turns into a link to the indicated ftp url. A few weeks ago, clicking on one of these would pop up the helper app dialog so that I could choose an audio app. In today's build, it just pops up a download dialog so there's no chance to set up a helper app. I tried going through prefs to set up a helper app for the .wav extension, but that mechanism (the helper apps panel in prefs) has never worked and isn't any better now. Apparently something has changed recently in the way we look at filenames in ftp and use extensions to choose mime types. "rheeet" in chatzilla is trivial, but it points to a more general problem which is a regression. Bbaetz says bz changed something in this area recently; starting there.
Akkana, could you mail me the following files please? /etc/mailcap /etc/mime.types ~/.mailcap ~/.mime.types mimeTypes.rdf prefs.js user.js (if you don't want to mail those last two, just let me know what the values of the "browser.helperApps.neverAsk.openFile", "browser.helperApps.neverAsk.saveToDisk", and "browser.helperApps.alwaysAsk.force" prefs are). > I tried going through prefs to set up a helper app for the .wav extension, but > that mechanism (the helper apps panel in prefs) has never worked and isn't any > better now. It should be working now... That was the last change I made -- make us pick up extensions from helper app prefs... I'd love to take a look at those files so I can try to reproduce this (needless to say, it worksforme with all the profiles I have here -- I either get a helper starting or a dialog asking what to do).
Status: NEW → ASSIGNED
Component: Networking: FTP → File Handling
Priority: -- → P1
Target Milestone: --- → mozilla0.9.7
Files sent to Boris. I don't have a personal .mailcap or mime.types on this particular machine; the ones in /etc are whatever Redhat 7.1 put there, since it's a fairly recently installed system (unless some other RPM has modified the files, which is possible, but RPM says both files belong to mailcap-2.1.4-2). They don't seem to have any WAV entries anyway. My mimeTypes.rdf does have a wav entry, but only because I tried to add it by hand via the prefs panel after I didn't get the popup the first time I clicked (and the entry is apparently ignored). My prefs.js has: user_pref("browser.helperApps.neverAsk.openFile", "audio%2Fx-wav"); which I didn't put there (it probably got there when I tried to add it via prefs). Incidentally, "never ask" doesn't seem to do anything, since I also have: user_pref("browser.helperApps.neverAsk.saveToDisk", "application%2Fx-tar"); and I ALWAYS get asked about tar files even though I've un-checked "always ask me" about a million times. (But maybe it's only broken on "saveToDisk"?) Did I miss anything? Let me know if you need more info.
ok.. Akkana, could you go into helper app prefs and click the "reset" button? That should clear those neverAsk prefs, and may well get things working for you. Not a fix, just a workaround. I haven't gotten the files yet... did you send them to firstname.lastname@example.org?
OK. Got the files. Here's the deal... We get a file with extension "wav". We try to look up the extension in helper app prefs. The code to do this actually looks for "WAV" because at one point we uppercased all the extensions we put in the external data source. This is no longer the case, however, as my experimenting shows.... In your case you have the extension "wav" listed in helper apps and we don't find it. I'll ask around for good ways to do all this RDF stuff case-insensitively... In any case, we don't find a handler in helper apps. So we look in /etc/mime.types for the content type for .wav. This has: audio/x-wav wav as the only entry for .wav, so we decide this file is of type audio/x-wav. Now we look for a handler for this type and don't find one. So we create a new mime info that defaults to save to disk and don't put up a dialog because of the user_pref("browser.helperApps.neverAsk.openFile", "audio%2Fx-wav"); pref. So we just put up a filepicker to save the file. Now as to what has changed... We _used_ to return a mime info based on the mime.types info instead of creating a new one. The info had no handler so the code forced it to "ask" and essentially overrode the pref. Then you unchecked the "always ask" button and reset the pref. And so it kept going :). We no longer do this in this particular case (that was an effect of a change I made to fix cases when we have a handler for an extension but not for the type), so suddenly we are obeying your "never ask" preference. But we still have no handler, so you get the behavior above. The moral of that story is that clicking the "Reset" button in preferences should fix this in this one case.... As long as you don't uncheck the "ask me" checkbox on the dialog that comes up (item #2 below will fix this "as long as"). What we should do to fix this bug: 1) Fix case issues when getting helper app stuff from prefs 2) Remove code in unix/nsOSHelperAppService.cpp that modifies the "ask me" pref so that this situation does not occur. Attaching a patch that does #2; #1 is more work, but I will try to get to it this weekend...
Indeed, clicking Reset did solve the problem. I got the helper app dialog and was able to specify /usr/bin/play, and the sound played correctly. Haven't tried the patch yet.
Comment on attachment 60959 [details] [diff] [review] patch r=law
Attachment #60959 - Flags: review+
Comment on attachment 60959 [details] [diff] [review] patch sr=mscott
Attachment #60959 - Flags: superreview+
Since people are reviewing this, I should note that the patch doesn't actually solve the problem. Boris is aware of the issues, and the patch doesn't make the current situation any worse, but its benefits won't be realized until bug 88330 is fixed. I'll tentatively add that dependency here, though Boris may want to track things differently.
Depends on: 88330
OK.. I've checked the patch in. It's likely to resolve some of the issues in bug 48948 if nothing else... Akkana, I think the bug you meant was bug 93173, not bug 88330... Adding that to dependency list, since the problems you describe certainly can't get better till that's fixed. I may just turn this bug into a tracker of "things to fix so the helper app dialog won't drive users insane"...
Depends on: 93173
pushing out to 0.9.8; I need to figure out what to do with this bug. :)
Target Milestone: mozilla0.9.7 → mozilla0.9.8
*** Bug 111328 has been marked as a duplicate of this bug. ***
Yeah. I'll keep this open to track the issues with that dialog for now....
Priority: P1 → P4
Target Milestone: mozilla0.9.8 → mozilla1.0
qa -> default
QA Contact: benc → sairuh
I'll get to the bugs this tracks someday, but it's not gonna happen till I finish my thesis.
Target Milestone: mozilla1.0 → Future
akkana, is this still a problem for you? i tested this with 2003.01.13.08 (comm trunk on linux rh8.0), and the helper app dlg appears for me. note: i have neither a helper app defined in my nscp prefs, nor is there an existing OS-association on my (well, none that nscp is picking up, but that's likely another issue). if it's still a problem for you, methinks it might be bug 93173, which might not have been fixed via the landing for 86640...
bug 93173 looks fixed to me... marking w4m --however, akkana, let us know if this is still a problem!
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.