38822 - netscape not loading Quick View Plus plug-in for MS word files.

Status: RESOLVED WORKSFORME

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

Description

[kirsten_fundanish]

After installing Quick View Plus on a system that has netscape 4.X, one can open 
an MS word file (any file with a .doc extension) from the hard drive and 
netscape will map the extension of the file to our plugin (which handles word 
documents, we claim all word mime types too) and load our plugin.  Netscape 6 is 
not looking for us at all.  Even if you try to download a .doc file from a 
server that gives the correct mime type, Mozilla will just say it's an 
unrecognized mime type.  
The last time I entered this bug I made the mistake of pointing out that the 
adobe acrobat reader plugin didn't work either.  So the guy fixed it for .pdf 
files but never even took the time to try the Quick View Plus plug-in, he noted 
that the marketing documentation only stated they had to have real player and 
adobe working.  There is obviously something wrong with the mime mappings, we 
are not even being called to handle the mime type.  We do not use java in 
anyway, so we should not have to upgrade our plugin for the new plugin API, but 
I can't even test our plugin because it never gets loaded!
Also, I noticed that there is no Help | About Plugins option, and the mime types 
and file extensions are not listed in the Preferences either.  I will attach a 
word document for testing if you like, but no web page should be needed since 
Netscape can use either mime types or file extensions to locate plug-ins.  Quick 
View Plus is far too large to attach here, but you can get a demo version from 
www.jasc.com under their link to Quick View Plus.

Comment 1

[Asa Dotzler [:asa]]

setting to NEW

Comment 2

[av (gone)]

This bug has been marked "future" because the original netscape engineer working 
on this is over-burdened. If you feel this is an error, that you or another 
known resource will be working on this bug,or if it blocks your work in some way 
-- please attach your concern to the bug for reconsideration. 

Comment 3

[av (gone)]

Now, as the full-page mode fixed, this one should work out of the net on html 
code like this: <a href="text.doc">Word File</a>, assuming the server sends 
right mime type for .doc files, say application/msword. It should not work out 
of local disk yet because of 43556. Adding dependency.

Comment 4

[Glenn Widener]

Do not close this bug unless you know what you are doing.  I (and many of our
customers) been waiting two years for someone to actually fix Netscape 6/Mozilla
so that plugins are started from MIME types and suffixes the same way they are
in Metscape 5.  This bug has been closed erroneously more than once...

Comment 5

[Glenn Widener]

The essence this bug is that no plugins are started based on full-page files,
except for EMBEDs and local file paths, and except a hack for PDF and real
player mime types.  The original bug report cites the Quick View plugin, I can
only speak for the SwiftView plugin (www.swiftview.com):

I downloaded the nightly build on 1/28/02, installed on Windows ME,
installed our SwiftView plugin (via Internet Explorer, since there still is no
Smart-Update installation support in Mozilla), copied the npsview.dll to the
Mozilla plugins directory (since we haven't added Mozilla/NS 6 to our installer
since they don't work yet), and find that:

Good:
 - there is now a help...about...plugins (wonderful!) - and refresh shows our
plugin correctly.  Just to be sure, I restarted Mozilla, and:
 - typing a path to a file in the address bar correctly starts and runs our
plugin.

Failed:
 - typing a URL to a file of our plugin's suffix in the address bar, or clicking
on a file: or http: url on a web page try to run the Windows application
registered for the suffix instead of the plugin.
 - an EMBED of a SwiftView-suffix file starts our plugin, but it's unable to
display the file in the page  It only works in a mode we support that displays
the file in an external window.  This we could investigate further, perhaps find
a workaround on our end...but it has always worked fine in NS 4.x...and has been
broken this way in Mozilla since at least Feb 2001.

Comment 6

[Boris Zbarsky [:bzbarsky]]

> - typing a URL to a file of our plugin's suffix in the address bar, or
> clicking on a file: or http: url on a web page try to run the Windows
> application registered for the suffix instead of the plugin.

Could you check what exactly the server is sending?  (And better yet, provide a
url to a testcase and to a place where your plugin can be gotten from?) If the
server is sending an ms-word mime type, I'm not sure how that's happening.  If
the server is sending application/octet-stream and we're using the extension to
find what to do, the problem may be in how
nsExternalHelperAppService::GetTypeFromExtension works.  It looks at the OS
settings before looking at the plugin settings....

Comment 7

[Mike Kaply [:mkaply]]

You have a totally different problem here.

The issue is that the mime type that is being used by SwiftView for PCX files is 
NOT a standard mime type.

If it was, things might work here.

Whose extension/mimetype mapping should have priority here, plugins or operating 
system?

Why did you come up with a new mime type for PCX instead of using image/pcx?

Comment 8

[Glenn Widener]

Everything you need to try SwiftView is at www.swiftview.com.

I'm not sure what you are talking about regarding pcx.  First of all, standards
are irrelevant - all that matters is that the plugin registers a MIME type
string with the Netscape plugin API, and if that MIME type string appears in the
HTML header, the plugin is called BEFORE ANYTHING ELSE.  Same goes for the
plugins registered suffixes.  This is how Netscape 5 and IE work (before IE
dropped plugin support, and for Active-X controls, when IE works...which it
doesn't always reliably, especially with POST requests). Second, here are the
MIME types and suffixes the SwiftView plugin registers - all are properly
registered with the authorities:

# application/cals-1840:ras,cal:Cals Raster File;
# image/pcx:dcx,pcx:PC-Paintbrush File;
# image/tiff:tiff,tif,001:Tagged Image File Format;
# application/vnd.hp-HPGL:hpgl,plt,hp,hpg,hgl:HP Graphics Language;
# application/vnd.hp-PCL:prn,pcl:HP Printer Control Language;
# application/vnd.SwiftView-ICS:svp,ics,vdt:SwiftView Command File;
# application/vnd.SwiftView-ZIP:zhp:Zipped SwiftView Files;

Comment 9

[Mike Kaply [:mkaply]]

When we open a local file, we don't have a mime type. We ask the operating 
system what the mime type is.

The operating system says "image/pcx"

We use this as the mime type.

I'm not saying this is wrong or right. I'm simply stating the facts and asking a 
few questions.

If we should be using the plugin mimetypes before the OS mimetypes, that is what 
needs to be changed here.

Can you give me an example of a webserver that serves a PCX file with your mime 
types?

My wager would be that most web servers serve PCX file with image/pcx, not your 
proprietary mime type.

Comment 10

[Glenn Widener]

> If we should be using the plugin mimetypes before the OS mimetypes, that is
what needs to be changed here.

That is correct.

> My wager would be that most web servers serve PCX file with image/pcx, not
your proprietary mime type.

It doesn't matter.  The decision depends only on matching the server and
plugin-registered mime types - the OS configuration is irrelevant.

It's not unusual for a web site to need to use a plugin for a given MIME type,
whereas some users don't want to use that plugin for viewing local files.  Or
they unwittingly install some app (or Microsoft installs it for them) that would
interfere with the web site's use of a plugin.  Even worse, there is no official
registry for suffixes, so Microsoft can at any time decide to take over a suffix
with some app they preinstall, suddenly rendering that suffix unusable.  This
already happened to us with .ics.  The problem is compounded by IE's tendency to
randomly decide to key off a suffix on the URL instead of obeying the MIME
type.  DONT FOLLOW THIER BRAIN-DEAD EXAMPLE!

Moral - depend on the Microsoft registry, and especially suffixes, as little as
possible.  This is the Internet, not an extension of Windows.

Comment 11

[Mike Kaply [:mkaply]]

But if the server gives us image/pcx, we are going to invoke the operating 
system pcx viewer, correct?

The only cases where your plugin is used is:

a. The server gives us the exact mime type that corresponds to the plugin 
(image/vnd.SwiftView-pcx)

b. The server gives us a PCX file with no mime type

c. a local file is being loaded on the hard drive where there is no mime type.

Comment 12

[Glenn Widener]

I took this discussion off-line with "Michael Kaply" <[e-mail]>, and
got him to agree that:

"a. is definitely a bug and I will look at that."

"a." is:

Mozilla doesn't start a plugin under this condition: The server gives us the
exact mime type that corresponds to the plugin.

(and it doesn't, except maybe for an ugly hack for Acrobat/shockwave)

Can someone please push this bug to P1, now?????  We are tired of customer
complaints that Netscape 6 doesn't work for simple url's with the correct MIME
type.

The following also fail, but aren't as critical:

> b. The server gives us a file with a suffix matching the plugin list, but with
no mime type.

Even in this case, if the plugin registers a suffix, and the URL/file ends in
the suffix, the browser should start the plugin before looking at the OS. 
Plugins are almost always presumed better than running an external app.

> c. a local file is being loaded on the hard drive where there is no mime type.

Ditto b - run the plugin if suffixes match, else lookup the suffix in the OS.

Comment 13

[rubydoo123]

bug review: we believe that this is now functional, marking as wfm to get on QA
radar

Comment 14

[Peter Lubczynski]

Please do not morph bugs and include more than one issue per bug. This bug
orrignally looked to report general problems with QV or full-page plugins. Those
general problems seem to be solved so please open a sperate bug for EACH other
problem found.

Please report seperate problems with the SwiftView plugin, reading full-page
plugin extension, or problems with the EMBED tag in sperate bugs.

When opening new bugs, please be sure to include:
* detailed description of the problem with steps to reproduce
* links to resources like plugins needed to see this bug
* simplified testcases to clearly show the problem
* actual and expected results including resources like screenshots, HTTP logs, 
and about:plugins output if needed

Mozilla plugin support does not use anything from the system like reading the
Windows registry. Plugin mime-type and extension mappings are read directly from
the plugin DLL. As long as the extension and mime type are listed in the DOM
pluign/mime-type array (as seen in about:plugins), we should use those. If this
is not the case, please open a new bug.

However, helper applications are different story than full-page and embedded
plugins. If we need to launch a helper application (like Word), then we will
consult system settings like the Windows registry.