Closed Bug 163568 Opened 21 years ago Closed 21 years ago
Download dialog appears for Shockwave Flash content
I am using NS 7.0-to-be on Win2k. Going to site, I get a download dialog asking me what I want to do with type "Shockwave Flash Object", mime type being application/octet-stream. If I select Open in Netscape, the page seems to come up as black (nothing visible), and after a while I get a "Open With" dialog from the OS asking me what I want to do with 'main-1.swf'. Site is completely unusable. This works in IE6.
It's a bad server configuration -- and the mime type in the file is set to application/x-shockwave-flash, the server is feeding a mime type of application/octet-stream, which is incorrect. The swf will not even open if you select to open the file directly in Flash. The IE swf file is ActiveX, so it is not even the same file.
Talked with Peter about this one and he wants to ensure that we at least take a look at the extention and try to resolve the issue from that perspective, and not totally rely on the server feedback.
Assignee: beppe → peterl
Priority: -- → P3
Target Milestone: --- → mozilla1.2beta
Here's a patch Tony and I worked on yesterday to fix this bug. Please review.
Slight change....using the contract ID caused a second nsPluginHostImpl to be created. This works better.
Attachment #97025 - Attachment is obsolete: true
Comment on attachment 97826 [details] [diff] [review] patch v1.1 r=av
Attachment #97826 - Flags: review+
Comment on attachment 97826 [details] [diff] [review] patch v1.1 I have a couple of suggestions: 1. When checking if string is empty, do not call Length(), call IsEmpty(). Makes the code self explaining. 2. I really don't like adding dependencies, so if you can think of any way that we could avoid making uriloader NOT depend on plugins that would be great. This is the reason I did not yet give the sr yet, I want to find out how important it is that uriloader dependencies don't grow.
new patch: 1. fixed IsEmpty() 2. Moved code to docshell which already depends on plugins
Attachment #97826 - Attachment is obsolete: true
Comment on attachment 99234 [details] [diff] [review] patch v.2 sr=heikki
Attachment #99234 - Flags: superreview+
Comment on attachment 99234 [details] [diff] [review] patch v.2 r=av
Attachment #99234 - Flags: review+
patch in trunk, marking FIXED
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Note: The patch for this bug causes bug 169991 (not possible to read news posts from Australia)
Status: RESOLVED → VERIFIED
This caused regression bug 175368.
It sounds like the Mozilla developers have snuck in a form of MIME-type second-guessing, a la MSIE, something that is very much against the standards and can have nasty consequences. In this case, the presence of anything at the end of a URL that looks like the file extension of a plugin data type triggers the plugin whether appropriate or not. One of the sillier results is the inability to read newsgroup posts from Australia, because the ".au" TLD resembles the file extension of a type of audio file. One can wonder / fear that a future version might attempt to execute anything from a .com domain under MS-DOS, since .com is an extension for DOS executables. I've got a test script in my site that detects some of this sort of MIME second-guessing (it trips up MSIE sometimes); the output of the following URLs is always of type text/plain, and a standards-compliant browser should show it that way: http://webtips.dan.info/cgi-bin/plaintext.pl http://webtips.dan.info/cgi-bin/plaintext.pl/test.html http://webtips.dan.info/cgi-bin/plaintext.pl/test.gif http://webtips.dan.info/cgi-bin/plaintext.pl/test.au http://webtips.dan.info/cgi-bin/plaintext.pl/test.swf http://webtips.dan.info/cgi-bin/plaintext.pl/test.exe
You need to log in before you can comment on or make changes to this bug.