163568 - Download dialog appears for Shockwave Flash content

Status: VERIFIED FIXED

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

Description

[Heikki Toivonen (remove -bugzilla when emailing directly)]

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.

Comment 1

[rubydoo123]

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.

Comment 2

[rubydoo123]

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.

Comment 3

[Peter Lubczynski]

Attachment: patch v.1

Here's a patch Tony and I worked on yesterday to fix this bug. Please review.

Comment 4

[Peter Lubczynski]

Attachment: patch v1.1

Slight change....using the contract ID caused a second nsPluginHostImpl to be
created. This works better.

Comment 5

[av (gone)]

Comment on attachment 97826 [details] [diff] [review]
patch v1.1

r=av

Comment 6

[Heikki Toivonen (remove -bugzilla when emailing directly)]

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.

Comment 7

[Peter Lubczynski]

Attachment: patch v.2

new patch:

1. fixed IsEmpty()
2. Moved code to docshell which already depends on plugins

Comment 8

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Comment on attachment 99234 [details] [diff] [review]
patch v.2

sr=heikki

Comment 9

[av (gone)]

Comment on attachment 99234 [details] [diff] [review]
patch v.2

r=av

Comment 10

[Peter Lubczynski]

patch in trunk, marking FIXED

Comment 11

[WD]

Note:   The patch for this bug causes bug 169991 
(not possible to read news posts from Australia)

Comment 12

[shrirang khanzode]

.

Comment 13

[Boris Zbarsky [:bzbarsky]]

This caused regression bug 175368.

Comment 14

[Dan Tobias]

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