140975 - Wrong plug-in used when MIME type and file extension are inconsistent

Status: RESOLVED DUPLICATE of bug 96579

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

Description

[Jason Summers]

[build 2002042908]
Suppose you have two plug-ins installed:

1. "Plug-in AAA"; MIME type "application/aaa"; extension ".aaa"
2. "Plug-in BBB"; MIME type "application/bbb"; extension ".bbb"

and you encounter an embed tag like this:
  <embed src="foo.aaa" width=100 height=100>

or an object tag like this:
  <object data="foo.aaa" width=100 height=100></object>

and the "foo.aaa" document has a MIME type of "application/bbb" (sent by the
server in a Content-Type header).

File extensions are never supposed to be used when a MIME type is present, so
the browser should look at the MIME type, and decide to run Plug-in BBB.
Mozilla, however, runs Plug-in AAA in this situation.

Mozilla behaves correctly (runs BBB) if the embed or object tag includes a
"type" attribute reflecting the MIME type, or if you view the "foo.aaa" URL
directly, or if no plug-in for extension ".aaa" is installed.

See http://entropymine.com/jason/testbed/whichplugin/ for my test page using
Flash and Acrobat. When I try it, Mozilla fails (1) and (3). Nav4 has no problem.

Comment 1

[rubydoo123]

assigning to av and adding serge and peterl for info on what the logic should 
be. When the plug-in effort started: what was the logical process put into place 
 -- what is the sequence of events?

Comment 2

[Boris Zbarsky [:bzbarsky]]

confirming that we actually do this... (I was weirded out by it when looking
over this code sometime a few months back...)

Comment 3

[Jason Summers]

I did some more investigating... I think this is essentially the same as bug
127963, which has been marked a duplicate of bug 96579, whose summary is
completely misleading.

Mozilla sometimes decides what to do with embedded objects too early (before
downloading the HTTP headers). The issue is (therefore) not limited to plugins
-- Mozilla has considerable problems with embedded internally-handled types like
text/html and image/gif when they have unusual file extensions.

Note that the correct logic depends on whether you think bug 95549 should be
fixed or not. (Personally I do not think it should be -- that would be a
disaster.) If it *is* fixed, then Mozilla will effectively ignore all TYPE
attributes for documents retrieved via HTTP.

Comment 4

[av (gone)]

I remember a discussion some time ago about this issue but don't remember what
we decided. Please correct me if I am wrong. TYPE attribute should take
precedence, if it is missing we should probably look at the HTTP headers and so
on. So in order of precedence:
  1. TYPE attribute
  2. mime type reported by server
  3. OS level file ext to mime type mapping
  4. choose plugin by file extension only

The first two are most the controversial I would guess.

Comment 5

[Jason Summers]

In my opinion, plug-in-registered file extensions (4) should have priority over
OS mappings (3). Actually, I think OS mappings should be ignored altogether when
selecting a plug-in.

If OS mappings are used, then the plug-in selected will sometimes depend on what
(not-necessarily-browser-related) applications the user happens to have
installed on his computer, and even on the order in which they were installed,
and how they are configured. Although this won't apply in most cases (because a
Content-Type header will be present), situations like this can be very
frustrating for plug-in developers and users.

An exception could perhaps be made for the "file:" URL scheme, but it may not be
worth the extra confusion.

Comment 6

[serge (gone)]

*** Bug 112335 has been marked as a duplicate of this bug. ***

Comment 7

[Jesse Moorman]

My Mozilla 1.0 installation [W2K] not only gets the wrong plugin, it crashes on
the 'object' and 'embed' links on the test URL.

I came to search Bugzilla because recently Mozilla is trying to open or to
save-to-disk almost everything as a PDF files even if NOT PDFs. I'm not sure if
that bug is different, or if it has been reported. I'm not really sure how to
check the MIME types, so I don't know how to test this one against the Bugzilla
discriptions.

Comment 8

[rubydoo123]

peter : plug-in branch work

Comment 9

[Ian Jackson]

Another strange effect of this bug (these bugs?) is that it is possible to get
firefox to display a dialogue box:

  You have chosen to open ubuntu1.png
  which is a: PNG image
  from: http://www.ubuntulinux.org

  What should Firefox do with this file?
  (*) Open with [ Image Viewer (default) ] [V]
  ( ) Save to Disc
  [ ] Do this automatically for files like this from now on

which is obviously completely barking !

I can reproduce this at the moment as follows:
  1. Visit http://www.ubuntulinux.org/screenshots/document_view
  2. Left-lick on the top-left image.

The image has URL http://www.ubuntulinux.org/include/ubuntu1.png and the server
erroneously says Content-Type: text/plain.

Firefox should believe the Content-Type.  If it is thought desirable not to
believe it in some cases (which I strongly disagree with) then it should
entirely fail to believe it and entirely believe the file extension instead.

What we have at the moment is Firefox being confused - it can't make up its mind
what the file type is.

Comment 10

[Mihai Morar, (:MihaiMorar)]

Based on Comment 3 Resolved Duplicate.