Download dialog appears for Shockwave Flash content

VERIFIED FIXED in mozilla1.2beta

Status

()

Core
Plug-ins
P3
normal
VERIFIED FIXED
15 years ago
15 years ago

People

(Reporter: Heikki Toivonen (remove -bugzilla when emailing directly), Assigned: Peter Lubczynski)

Tracking

({testcase})

Trunk
mozilla1.2beta
x86
Windows 2000
testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [PL2:NA], URL)

Attachments

(1 attachment, 2 obsolete attachments)

4.46 KB, patch
av (gone)
: review+
Heikki Toivonen (remove -bugzilla when emailing directly)
: superreview+
Details | Diff | Splinter Review
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

15 years ago
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

15 years ago
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

Updated

15 years ago
Status: NEW → ASSIGNED
Keywords: patch, review, testcase

Comment 3

15 years ago
Created attachment 97025 [details] [diff] [review]
patch v.1

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

Comment 4

15 years ago
Created attachment 97826 [details] [diff] [review]
patch v1.1

Slight change....using the contract ID caused a second nsPluginHostImpl to be
created. This works better.
Attachment #97025 - Attachment is obsolete: true

Comment 5

15 years ago
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.

Comment 7

15 years ago
Created attachment 99234 [details] [diff] [review]
patch v.2

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 9

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

r=av
Attachment #99234 - Flags: review+

Comment 10

15 years ago
patch in trunk, marking FIXED
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED

Comment 11

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

Comment 12

15 years ago
.
Status: RESOLVED → VERIFIED
This caused regression bug 175368.

Comment 14

15 years ago
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.