Closed Bug 22954 Opened 25 years ago Closed 24 years ago

mapping of URL's to plug-in MIME types isn't working

Categories

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

Product:
Core Graveyard
Component:
Plug-ins
Platform:
x86
All
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: glennw, Assigned: serhunt)

References

(
URL
)

Details

(Whiteboard: [nsbeta2+]Exception Feature) 

win32-m11-fullcircle.zip, installed on win98, won't run our plug-in (SwiftView,
in extensive use by 1000's of customers for 3 years), even though the plugin is
running under Nav 4 on the same box.  I put the npsview.dll in a plugins dir
under Mozilla's bin directory, no help.

Click on the download item on our homepage, install the plugin using Nav 4, try
the test examples.
Could you please provide some test example links here? I was unable to find them
on your company website. Thanks!
Target Milestone: --- → M18
Status: NEW → ASSIGNED
4/10/00: glennw@swiftview.com: I've just retried SwiftView plugin under Netscape
6 pr1 - Netscape still is not recognizing our plug-in MIME type (as it should
based on the resources in npsview.dll, which is installed in the plugins
directory), and is asking where to save/what program to run.

I've just submitted a bug against Netscape 6, that SmartUpdate doesn't work for
a number of reasons.  To try this bug, you should download SwiftView plugin from
www.swiftview.com with a pre-6 Netscape, and copy npsview.dll to the 6.0 plugins
directory.
 
Some more testing - Turns out that Netscape 6 will start our plug-in from an
EMBED - it's the mapping of URL's to our MIME types that isn't working.  It
isn't working for Acrobat either.

For an EMBED, Netscape crashes at various points in plug-in initialization. 
An EMBED for Acrobat shows no embedded control, and the mouse seems to get hung
in a text selection operation.

Revising summary and marking acrobat.

Glenn: we need more detail in order to fix this. In particular:
1) Please post to the web or attach to this report a simplified test case for 
reproducing the problem.
2) Please provide more details about the mapping of URLs to MIME types (e.g. 
what is your plug-in's MIME type?)
3) If you see crashes, please open a separate bug report for each crash. FYI 
each Bugzilla report should deal with a single issue so that each issue can be 
tracked to resolution individually.

Many thanks for your help!
Keywords: acrobat
Summary: Won't run our plug-in → mapping of URL's to plug-in MIME types isn't working
To reproduce, download SwiftView plugin from
http://www.swiftview.com/dload/dlmain.htm using pre-6 Netscape, and access
http://www.swiftview.com/tech/svrel.pcl.

SwiftView's MIME types (e.g. in the plug-in .dll) are:

   Mime Type                       Description      Filename Suffixes

   application/vnd.SwiftView-ICS   SwiftView        ics, svp, 001
   application/vnd.SwiftView-ZIP   Zipped SwiftView zhp
   application/vnd.hp-PCL          HP-pcl           pcl, prn
   application/vnd.hp-HPGL         HP-hpgl          hpg, hpgl, hgl, plt,
						    pwa, pwb, hp, sch
   image/tiff                      tiff             tif, tiff
   image/vnd.SwiftView-pcx         PC-Paintbrush    pcx, dcx
   image/vnd.SwiftView-cals        Cals             cal, ras

Sorry, I don't have a demo of an EMBED (which works) on the web site; I can get
one up for you if needed.

I tried this on seamonkey and an 'unknown file type' dialog pops up when I 
access the webpage mentioned. However, as Glenn said, this works fine on 4.x 
browser.
The problem could very well be between keyboard and chair, but it seems to me
that mozilla also does not map MIME-type to external applications too.

My end goal here is to fork an mp3 player to play music from:
http://artists.mp3s.com/artists/11/00soul.html

This is tested on Linux/i386 (with a proper mime.types and mailcap file) as well
as on Windoze 98 with the 05/19/00 build.

Nominating nsbeta2, recommend nsbeta2+. This breaks Acrobat IIUC, and Acrobat is 
one of the plug-ins that is listed on the beta2 criteria as being supposed to 
work both as a plug-in and as a helper app.
Keywords: nsbeta2
Giving [nsbeta2+]Exception Feature status for Helper Apps work.
Whiteboard: [nsbeta2+]Exception Feature
Looks like there are several issues in this bug.

1. Plugins do not work in full page mode.
I just checked in a fix for this one. So Acrobat is working again on things like 
<a href=file.pdf>file</a>
I also tried full page sound plugin (QuickTime)

2. File extensions are not correctly associated with mime types.
The HTML code like above is working correctly when it is on the net because the 
server probably gives us the content mime type in the stream. But if this is a 
local file nsMIMEService::GetFromExtension returns wrong mime type for pdf, 
namely text/html. This should be fixed by whoever owns this code.

3. Helper apps ARE different from full page plugins, so this part does not 
belong to the plugin module.

4. As to the link from original report http://www.swiftview.com/tech/svrel.pcl
For some reason nsLayoutDLF::CreateInstance receives wrong mime type, namely
text/xul, tries to create RDF viewer and fails.

So to my understanding, the plugin part of this bug is fixed, reassigning to 
mscott for further look. Not sure about component, setting Networking.
Assignee: av → mscott
Status: ASSIGNED → NEW
Component: Plug-ins → Networking
av gave me this bug to look into the follwing 3 issues:
1) file extensions are not always properly associated with the correct mime
type. This is already tracked in Bug #43556 --> we need to merge the mime info
service (which is just a hard coded list of extension to content type mappings)
with the uriloader/exthandler work I did which knows how to sniff the OS to
discover content types for file extensions.

2) implement launching of helper applications. This has been implemented and was
Bug #38374

3) the last issue was that the plugin was getting the wrong content type for the
url specified in this bug. According to av the server is returning the wrong
content type (or no content type) for that document? Or are we possibly ignoring
the content type in the document? This may also be fixed by 43556. Either that
or when the plugin registers we need to register the file extension the plugin
wants to handle (.pcl?? with a content type)

I'm going to mark this as a dup of the only remaining bug which is merging the
mime mapping work. 43556

*** This bug has been marked as a duplicate of 43556 ***
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
Reopening since Acrobat is still broken.
Status: RESOLVED → REOPENED
Component: Networking → Plug-ins
Resolution: DUPLICATE → ---
Taking it.
Assignee: mscott → av
Status: REOPENED → NEW
OS :All
OS: Windows 98 → All
in nsPluginHostImpl.cpp, it has some #ifndef XP_WIN code... this should either
be removed or changed to XP_PC...  I suggest removing it since XP_WIN isn't
defined and changing it to XP_PC prolly break stuff :-)  (just thought i'd
mention this here since you've been playing around with that area of code)

The stuff seems to be working... We actually need a bit sepatate path for 
Windows because we don't load dlls on initial scan for Windows only. And we also 
use different plugin finding procedure on Windows and in the rest of the world. 
And XP_WIN is defined in xp_core.h.
Looks like in fairly good shape now. Marking fixed.
Status: NEW → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
marking this one verified(getting off the radar) since acrobat problem is fixed 
and the swiftview plugin problem has been duplicated for the problem in bug 
43556. Will verify this (swiftview) after 43556 is fixed. (build 
used:20000071808)
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.