Closed Bug 163568 Opened 22 years ago Closed 22 years ago

Download dialog appears for Shockwave Flash content


(Core Graveyard :: Plug-ins, defect, P3)

Windows 2000


(Not tracked)



(Reporter: hjtoi-bugzilla, Assigned: peterl-bugs)




(Keywords: testcase, Whiteboard: [PL2:NA])


(1 file, 2 obsolete files)

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
Whiteboard: [PL2:NA]
Target Milestone: --- → mozilla1.2beta
Keywords: patch, review, testcase
Attached patch patch v.1 (obsolete) — Splinter Review
Here's a patch Tony and I worked on yesterday to fix this bug. Please review.
Attached patch patch v1.1 (obsolete) — Splinter 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

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.
Attached patch patch v.2Splinter Review
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

Attachment #99234 - Flags: superreview+
Comment on attachment 99234 [details] [diff] [review]
patch v.2

Attachment #99234 - Flags: review+
patch in trunk, marking FIXED
Closed: 22 years ago
Resolution: --- → FIXED
Note:   The patch for this bug causes bug 169991 
(not possible to read news posts from Australia)
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:
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.