158158 - [SwiftView/QuickView]Mozilla STILL won't run plugins on full-page URLs

Status: RESOLVED WONTFIX

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

Description

[Glenn Widener]

This is a resubmission of bug #38822, and a number of related bugs, since people
keep insisting over the last two years that they are fixed and closing them when
they are not fixed in general.

Bug #38822 was originally reported in conjunction with Quick View, and addressed
starting plugins on files and URL's.  The bug itself appears to affect all
plugins execpt for Acrobat and perhaps Quick Time, for which fixes were hacked
in.  Fixers should read bug #38822 carefully for a more complete picture of the
problems.

Bug #38822 had two parts: failure to start a plugin from a file, and from a
URL.  It appears that from-file works now, except for clicking on an item on a
directory list.  Starting from a URL is still a total failure.

By testing with the SwiftView plugin, Mozilla 1.1a, Build 2002061104, downloaded
after the last claim that bug #38822 was fixed, I have found that Mozilla still
pops the "What should Mozilla do" dialog when a link to a url is clicked that
returns MIME type and suffix that are both registered by the SwiftView plugin.

Registration of all of the plugin's mime types and suffixes, all marked Enabled
- Yes, is confirmed in the about:plugins dialog.

Mozilla is keying off the suffix and looking up the associated application in
the Windows registry.  Actually, it's even worse than that.  Sometimes it's
reporting a different suffix than that of the URL, another suffix registered by
the plugin for a different MIME type (both suffix and MIME are registered by the
plugin and to our standalone app in the OS).  And it always reports the
"friendly filetype name" from the registry for this wrong suffix. 

To recap, a browser should never pop a what-to-do dialog for a MIME type or
suffix registered in a plugin - it should silently run the plugin just as
Netscape 4.x does.  Further, unlike broken IE, it should always obey the MIME
type first, then try to lookup the suffix, first in plugins, then in the OS.

The SwiftView plugin can be downloaded from www.swiftview.com and test files are
available there as well.

Comment 1

[Kai Lahmann (is there, where MNG is)]

Bug 149705 ?

Comment 2

[Matthias Versen [:Matti]]

i see a mime-type problem. (win2k build 20020714.., no Plugin version in
about:plugins)

URL : http://www.swiftview.com/tech/2pages.hpg 
mime-type : application/vnd.hp-HPGL
installed plugin is active with : application/vnd.hp-HPGL
I get a download dialog with the mime-type in lowercase.

Comment 3

[Peter Lubczynski]

Matti, 
what's the HTTP server sennding back for content-type?

Comment 4

[Matthias Versen [:Matti]]

Peterl:
D:\moz_source>wget http://www.swiftview.com/tech/2pages.hpg
--22:49:50--  http://www.swiftview.com/tech/2pages.hpg
           => `2pages.hpg'
Resolving www.swiftview.com... done.
Connecting to www.swiftview.com[208.151.247.133]:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 57,252 [application/vnd.hp-HPGL]

Comment 5

[rubydoo123]

peterl

Comment 6

[Peter Lubczynski]

Is this the same as bug 149705? Can you copy paste the output of about:plugins here?

Comment 7

[Glenn Widener]

No, this is NOT bug 149705.  That bug (after a careful reread through the
noise), was a request for the following feature:

If the server returns it's default mime type, try to infer what plugin to run
based on the suffix.  Most servers default the default MIME type to text/plain,
hence the request was to treat "text/plain" as "unknown"; similar action for
"application/octet-stream".  This default of text/plain is an unfortunate
de-facto standard, hence it's not unreasonable to give "text/plain" special
treatment.

However, doing so leads to improperly configure servers, resulting in erratic
behavior with different browsers and client configurations, thus in many ways is
a very bad idea.  The best scenario would be for all browsers to behave the
same, ideally fail immediately if the server administrator has failed to do his
job and configure the MIME type.  Keep in mind that the server developer has
total control of both mimes and suffixes, and it's his responsibility to get the
MIME type right.

I just checked, and Netscape ignores suffixes on http:, showing text/plain as
text, while IE as usual tries to be clever with text/plain and infer and run the
plugin (without user query) from the suffix.  Given the current state of the
world, duplicating IE's behavior is the better choice.  What I will strenuously
resist is any mis-construing of bug 149705 as a request for special treatment
for certain suffixes, or any MIME type other than "text/plain" or
"application/octet-stream" - that way is chaos (also known as Internet
Explorer!)

This bug, 158158, is a report that Mozilla is failing to run the plugin when
BOTH MIME type and suffix match the plugin.  However, beyond this, the ABSOLUTE
RULE is that if the http: MIME type matches, regardless of suffix, run the
plugin, no questions asked.  The fact that IE can violate this rule is a
disaster bug in IE that has caused us endless pain - in fact making it
impossible to reliably generate a plugin file from a POST request!

Consider also the following recent occurance:  Microsoft introduced an app that
takes over a suffix that we have been using for years for files placed on web
servers.  Because if IE's penchant for sometimes ignoring MIME types and using
suffixes, we now have to recommend that server admins change all their file
suffixes!  Because there is no official registrar for suffixes, I'm sure this
will happen again.

Our plugin's mime/suffix table in Netscape, Mozilla and ActiveX control in IE
are the same:

       Mime Type                             Description               
Suffixes       
application/vnd.SwiftView-ZIP       Any of above, zipped (*.zhp)           
zhp        
application/vnd.SwiftView-ICS          SwiftView Command File              
ics         
application/vnd.hp-PCL               HP Printer Control Language        prn
pcl       
  application/vnd.hp-HPGL               HP Graphics Language       hpgl plt hp
hpg hgl
       image/tiff                      Tagged Image File Format     tiff tif
001   
       image/pcx                          PC-Paintbrush File             dcx
pcx       
  application/cals-1840                   Cals Raster File               ras
cal        

Comment 8

[Peter Lubczynski]

Reporter:
Can you try this in a recent nightly?

Comment 9

[Glenn Widener]

I downloaded today's nightly from
ftp://ftp.mozilla.org/pub/mozilla/nightly/latest/mozilla-win32-installer-sea.exe
and nothing is fixed yet.  In fact, I believe I previously saw it work for local
filepath links on an html page, but now that doesn't work either - only typing
the filepath in the address bar works.

Comment 10

[rubydoo123]

future

Comment 11

[Clint Silvester]

Hi, I'd like to request this bug be looked at.  We are a title company and we
use many different document viewers.  I'd like to use Mozilla here instead of IE
and outlook, but we keep butting our heads on these plugins.  One major one is
this swiftview plugin.  The plugin will open the swiftview viewer if directly
linked to a file, but inline doesn't work for us.  I can't give an example url
since all the ones i've seen require a login.  Has there been any more
info/progress on this bug?

Comment 12

[BMO Automation]

Resolving as wont fix, plugin support deprecated in Firefox 85.