Closed Bug 198578 Opened 17 years ago Closed 17 years ago

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

Categories

(Core Graveyard :: File Handling, defect)

x86
Windows 2000
defect
Not set

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 184971

People

(Reporter: hick.bugzilla, Assigned: law)

References

()

Details

Attachments

(1 file)

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
What URL does it happen on?
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.
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
Attached file Requested log file
Summary: alwaysask for user defined helper MIMEs is being ignored - being treated as set → always ask for user defined helper MIMEs is being ignored - being treated as set
biesi, can you repro this on windows?  I cannot on Linux.... 
huh, actually, I can
Status: UNCONFIRMED → NEW
Ever confirmed: true
to file handling, I guess.

I tested on win2k build 2003031808
Assignee: peterlubczynski → law
Component: Plug-ins → File Handling
QA Contact: bmartin → petersen
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?
(and yeah, if I change the mimetype in preferences->helper apps to
audio/x-mpegurl, it works)
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?
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
the mimetype on that nsIMIMEInfo is "audio/mpegurl".
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...
Whiteboard: DUPEME
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 ***
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → DUPLICATE
Whiteboard: DUPEME
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.