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!
4/10/00: email@example.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!
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.
Giving [nsbeta2+]Exception Feature status for Helper Apps work.
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.
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 ***
Reopening since Acrobat is still broken.
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.
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)