I noticed the bug in ns4xPlugin methods, but I believe the cause is elsewhere. Some initialization problem most likely. Anyway, all the ns4xPlugin methods seem to happily use npp->ndata before checking that npp != 0. If this happens on NT the app dies silently. There should be an NS_ASSERTION as the first thing in each method to check npp. This is a bit weird. This does not happen for all plugins. I have tested this with 3 different plugins: - ActiveCGM [CGM image] (works ok) - Dr. DWG [DWG image] (in _status: npp == 0, silently dies) - Acrobat [PDF file] (_useragent notices mPluginManager == 0 and asserts) However, if I first open a document containing a CGM graphic, then the other plugins work just fine. This problem has also crept in sometime after the 1998-10-08 tarball because these plugins work with that version. You can get the above plugins from: http://www.intercap.com/ http://www.drdwg.com http://www.adobe.com

Looking into it...

I have a fix. It seems that we were calling into the NP_Initialize entry point before we had set up and created the ns4xPlugin object. Hence, the mPluginManager was not set up yet either. The plugin, in NP_Initialize, tried to call back into the browser with NPN calls, failing because nothing was set up. Moving the call into the ns4xPlugin->Initialize routine fixes the problems. I will check this in Sat because I have to go home and can't monitor the tree status tonight.

I have a fix. It seems that we were calling into the NP_Initialize entry point before we had set up and created the ns4xPlugin object. Hence, the mPluginManager was not set up yet either. The plugin, in NP_Initialize, tried to call back into the browser with NPN calls, failing because nothing was set up. Moving the call into the ns4xPlugin->Initialize routine fixes the problems. I will check this in Sat because I have to go home and can't monitor the tree status tonight.

Fixed 11.22.98, 3:14PM

I just had time to do a little testing, and it looks like this problem has not been completely fixed. Namely, I can not get the Dr. DWG plugin to work, Gecko (isn't that the new official name now:) crashes when I try to open a document which has embedded DWG image. It does not help if other plugins have been succesfully loaded, DWG just causes crash every time. I notice the problem in here: nsresult ns4xPlugin::Initialize(nsISupports* browserInterfaces) { . . . // Execution of the following line clears the call stack in the // debugger, and access violation is reported when continuing // with the run if (fInitialize(&ns4xPlugin::CALLBACKS) != NS_OK)

The latest checkins by amusil improved the situation somewhat: now Dr. DWG plugin works if some other plugin has been succesfully used before that. However, when I step line at a time in the debugger (starting from the ns4xPlugin functions and ending in nsObjectFrame) everything works correctly. So maybe it is some kind of a timing issue, the plugin or Gecko being too slow or something like that... maybe there is something wrong with threads, yikes!

I'll check it out...

heikki - can you point me to a page that loads the Dr. DWG plugin (I guess a page that has a .dwg image)?

Sorry for the long delay, I was on vacation... I created a test page at http://www.doczilla.com/demos/html/index.html which has links to documents that include the three formats that I use for testing, i.e. DWG, CGM and PDF. There is also a gzipped archive that contains all those files on the web. The page I created will propably go away once this bug is fixed for good. Current situation: Examples loaded directly from this page: Nothing works, Gecko always crashes Examples installed on your local machine: PDF works DWG works if some other plugin has been used before it; if DWG is the first plugin that is used it crashes Gecko CGM plugin does not display anything

*Sigh* I should have stayed on vacation... Anyways, CGM and PDF work the same way, i.e. on local disk they work fine. There is still the weird problem with DWG. Network connection seems to be trickier: when the first plugin loading happens over network, Gecko always crashes. If the first plugin is loaded from hard disk, docs over http connection seem to work also. On some rare occasion I seem to get everything working correctly once or twice; when that happens there appears to be some sort of a delay over network, hard disk or other programs may have caused some slowing down. I have a P400 with 256k connection if that has anything to do with this.

Setting all current Open Critical and Major to M3

per leger, assigning QA contacts to all open bugs without QA contacts according to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser

reassigning to Greg Lynn as QA contact

Alex advise on status of this bug; do we need more, is it still a bug, etc.

Looks like this is fixed too.

Dev thinks this is fixed now. Heikki can you try latest builds and see if this is fixed for you? Above URL results in page Not Found error.

Sorry about the URL, our webserver went through reorganization and this directory was missed. The new URL should now work. I haven't had time to check the status of bugs I have reported but I will try to do that early next week (Monday - Tuesday). Last week I was in California (XTech'99), and visited Netscape as well (hi Alex & Rick!) so that is why you did not get any response from me during the last couple of weeks...

Something furry is going on here. Do you all have plugins working correctly? I can not get any of the three plugins I have been testing to work anymore. CGM plugin comes closest, but it only displays white (I can tell the plugin loaded because I get the plugin's menu with right-click). The viewer also finds all the plugin DLLs (the debug messages in the DOS window show this). DWG and PDF plugins just cause crash all the time. It does not matter if I access files locally or from the network. I just grabbed a latest nightly build: it works almost correctly (once I set the PATH variable <bug #1418>). Problems: if I open PDF plugin first, it only displays white (right-click on plugin area crashes, also back button does not take me to previous doc after which nothing seems to work). If I open CGM or DWG first, then everything works like a charm. Have build options changed or something like that? Alex, send me your environment info? Of course my build is debug and nightly build is opt, so maybe that has something to do with this? I am reopening this bug. I also reworded summary. I updated the URL doc.

The Adobe plugin works fine for me. FYI - your test pages are no longer available

All of these plugins work fine for me. Go to: http://www.drdwg.com/webviewers/netview/nvsample.htm for DWG, http://www.intercap.com/demozone/assembly.cgm for CGM, http://www.adobe.com/ for pdf My build env is: _MSC_VER 1100 CM_BLDTYPE dbg CVS_CLIENT_PORT 2605 MODULAR_NETLIB 1 MOZ_BITS 32 MOZ_DEBUG 1 NGLAYOUT_PLUGINS 1 OS_TARGET WINNT STANDALONE_IMAGE_LIB 1 You also need to set your MOZ_SRC, MOZ_TOOLS and CVSROOT.

Andrei also has this working on his build and machine. Marking this fixed.

Will verify in morning

I have tried just about everything except reinstalling everything on my machine, but nothing helps: my own build always crashes when Gecko opens a plugin stream and the nightly build works except when the first plugin load is Acrobat. I am trying to get my coworkers checking this out too, but as far as I am concerned I am finished with plugins :( Btw Alex, check the URL field at the top, it should point to the updated test docs.

March 18 M3 timestamp 8pm build, apprunner, adobe and dwg plugin work for me. Does not matter if Adobe is loaded first or 2nd. Heikki take another look with this latest build if you could please.

My computer is busted: plugins simply do not work in Gecko. And after I reinstalled sp 3 lots of other stuff stopped working as well... Ah well, the joys of Windows. Another guy here at Citec tried my tests and everything seems to work ok for him. So I am marking this verified.