198578 - always ask for user defined helper MIMEs is being ignored - being treated as set

Status: RESOLVED DUPLICATE of bug 184971

(Core Graveyard :: File Handling, defect)

Description

[hick.bugzilla]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030319
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030319

Alwaysask for user defined MIMEs is being ignored - a dialogue is always
produced no matter what the setting. The setting in Preferences->Helper
Applications->Edit is always unselected !


Reproducible: Always

Steps to Reproduce:
1. "Run" a document with an "unknown" MIME
2. Make sure "Always show this diaglogue ..." is unselected
3. Run another document with the same MIME type

Actual Results:  
The dialogue is shown again

Expected Results:  
The dialogue should not be shown

Occurs with 1.3 too - I get the impression this is probably an old bug/problem
which has just reappeared

Comment 1

[Boris Zbarsky [:bzbarsky]]

What URL does it happen on?

Comment 2

[hick.bugzilla]

http://artists.iuma.com/site-bin/streamartist.m3u?aid=105996

is a random IUMA example which demonstrates the problem.

I have this helper defined:

MIME: audio/mpegurl
Desc: Winamp playlist file
Ext : m3u
      Open it using default application

for launching these files to WinAmp.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Could you please do the following, from a prompt:

set NSPR_LOG_FILE=c:\log.txt
set NSPR_LOG_MODULES=nsHttp:5
\path\to\mozilla\mozilla.exe

Load that one URL.  Then quit. This will create a log of the HTTP headers in the
file c:\log.txt; attach this log to this bug using
http://bugzilla.mozilla.org/attachment.cgi?bugid=198578&action=enter

Comment 4

[hick.bugzilla]

Attachment: Requested log file

Comment 5

[Boris Zbarsky [:bzbarsky]]

biesi, can you repro this on windows?  I cannot on Linux.... 

Comment 6

[Christian :Biesinger (don't email me, ping me on IRC)]

huh, actually, I can

Comment 7

[Christian :Biesinger (don't email me, ping me on IRC)]

to file handling, I guess.

I tested on win2k build 2003031808

Comment 8

[Christian :Biesinger (don't email me, ping me on IRC)]

oh....
from the http log attachment:
808[dd7100]:   Content-Type: audio/x-mpegurl

Interestingly, this does not match the _displayed_ mime type. bz, and idea why?

Comment 9

[Christian :Biesinger (don't email me, ping me on IRC)]

(and yeah, if I change the mimetype in preferences->helper apps to
audio/x-mpegurl, it works)

Comment 10

[Boris Zbarsky [:bzbarsky]]

Hmm?  The helper app dialog shows audio/mpegurl?

This may be a duplicate of a bug I have floating about where the Windows version
of GetFromMIMEType will happily produce a MIMEInfo which has a _different_ MIME
type.  Since the code expects GetFromMIMEType to be sane, we don't reset the
type afterward...

Could you check what the GetFromMIMEType call at the top of
nsExternalHelperAppService::DoContent returns?  In particular what the type set
in that MIMEInfo is?

Comment 11

[Christian :Biesinger (don't email me, ping me on IRC)]

interesting... HKCU\.m3u\Content Type is audio/mpegurl... and
HKEY_CLASSES_ROOT\MIME\Database\Content Type\audio/x-mpegurl\Extension is
.m3u... maybe this has something to do with this bug

I'll check what you suggested shortly

Comment 12

[Christian :Biesinger (don't email me, ping me on IRC)]

the mimetype on that nsIMIMEInfo is "audio/mpegurl".

Comment 13

[Boris Zbarsky [:bzbarsky]]

Yeah, the setup in comment 11 is known broken -- we have a bug on that 
somewhere....  Biesi, this depends on that bug on merging the two GetFrom* 
funcs...

Comment 14

[Christian :Biesinger (don't email me, ping me on IRC)]

ok, this would be a duplicate of bug 184971 and should be fixed now by the bug
147679 checkin

*** This bug has been marked as a duplicate of 184971 ***