113908 - No helper app dialog for .wav file on ftp site

Status: RESOLVED WORKSFORME

(Core Graveyard :: File Handling, defect, P4)

Description

[Akkana Peck]

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.

Comment 1

[Boris Zbarsky [:bzbarsky]]

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).

Comment 2

[Akkana Peck]

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.

Comment 3

[Boris Zbarsky [:bzbarsky]]

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 [e-mail]?

Comment 4

[Boris Zbarsky [:bzbarsky]]

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...

Comment 5

[Boris Zbarsky [:bzbarsky]]

Attachment: patch

Comment 6

[Akkana Peck]

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 7

[Bill Law]

Comment on attachment 60959 [details] [diff] [review]
patch

r=law

Comment 8

[Scott MacGregor]

Comment on attachment 60959 [details] [diff] [review]
patch

sr=mscott

Comment 9

[Akkana Peck]

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.

Comment 10

[Boris Zbarsky [:bzbarsky]]

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"...

Comment 11

[Boris Zbarsky [:bzbarsky]]

pushing out to 0.9.8; I need to figure out what to do with this bug.  :)

Comment 12

[Boris Zbarsky [:bzbarsky]]

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

Comment 13

[Boris Zbarsky [:bzbarsky]]

Yeah.  I'll keep this open to track the issues with that dialog for now....

Comment 14

[[e-mail]]

qa -> default

Comment 15

[Boris Zbarsky [:bzbarsky]]

I'll get to the bugs this tracks someday, but it's not gonna happen till I
finish my thesis.

Comment 16

[sairuh (rarely reading bugmail)]

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...

Comment 17

[sairuh (rarely reading bugmail)]

bug 93173 looks fixed to me... marking w4m --however, akkana, let us know if
this is still a problem!