Acrobat Reader : 4.0.5 on MAC OS 9.0 Seamonkey crashes when I try to view a pdf file on the url mentioned above. Stack trace : Trigger Type: Program Crash Trigger Reason: PowerPC access violation Call Stack: (Signature = 0xc005ad00 0fc67f7a) 0xc005ad00 PDFViewer + 0x5f0 (0x16a539f0) PDFViewer + 0x1a3b8 (0x16a6d7b8) PDFViewer + 0x1d2f0 (0x16a706f0) PDFViewer + 0x6504 (0x16a59904) PDFViewer + 0x7f4 (0x16a53bf4) PDFViewer + 0x12d0 (0x16a546d0) ns4xPlugin::CreatePlugin() [ns4xPlugin.cpp] nsPluginHostImpl::GetPluginFactory() [nsPluginHostImpl.cpp] nsPluginHostImpl::SetUpPluginInstance() [nsPluginHostImpl.cpp] nsPluginHostImpl::InstantiateFullPagePlugin() [nsPluginHostImpl.cpp] PluginViewerImpl::CreatePlugin() [nsPluginViewer.cpp] PluginViewerImpl::StartLoad() [nsPluginViewer.cpp] PluginListener::OnStartRequest() [nsPluginViewer.cpp] nsDocumentOpenInfo::OnStartRequest() [nsURILoader.cpp] InterceptStreamListener::OnStartRequest() [nsCachedNetData.cpp] nsHTTPServerListener::FinishedResponseHeaders() [nsHTTPResponseListener.cpp] nsHTTPServerListener::OnDataAvailable() [nsHTTPResponseListener.cpp] nsOnDataAvailableEvent::HandleEvent() [nsAsyncStreamListener.cpp] nsStreamListenerEvent::HandlePLEvent() [nsAsyncStreamListener.cpp] PL_HandleEvent() [plevent.c] PL_ProcessPendingEvents() [plevent.c] nsEventQueueImpl::ProcessPendingEvents() [nsEventQueue.cpp] nsMacNSPREventQueueHandler::ProcessPLEventQueue() [nsToolkit.cpp] nsMacNSPREventQueueHandler::RepeatAction() [nsToolkit.cpp] Repeater::DoRepeaters() [nsRepeater.cpp] nsMacMessagePump::DispatchEvent() [nsMacMessagePump.cpp] nsMacMessagePump::DoMessagePump() [nsMacMessagePump.cpp] nsAppShell::Run() [nsAppShell.cpp] nsAppShellService::Run()

Adding crash keyword.

Marking acrobat. Nom. nsbeta3, recc. nsbeta3 stopper. Acrobat is #2 most popular plug-in per HotBot; don't want it to crash.

Shrirang, would you try this with our recent changes?

i will try this today and report.Thnx

I tried this on mac today. This is behaving exactly as on linux. The file seems to download but nothing happens after 100% download is done. I have the "PDFViewr' plugin in the plugins folder. The plugin does not launch. But there is no crash and no blank page pops up (like it used to on linux). Build used:2000071208.

Removing crash keyword per shrir. shrir--would you please retest?

Acrobat Reader 4.0 I tried manually putting the 'pdfviewer' file in mozilla|plugins folder and launching the above test url thru seamonkey. The file seems to download to 100% and gets saved on the desktop. Acrobat reader does not launch at all. I am changing the summary to reflect this.

Note: working fine on linux m17 build 2000080414.

PDT agrees P1

Note that per bug 50364 Acrobat's not launching on Linux either right now. Could that be a DUP of the same issue? Or are the bugs related?

Erik, I just updated bug 50364. It's working fine now on linux. Basically that bug was for a problem with acrobat as a helper app on linux. This bug is for acrobat as a plugin which has not worked earlier. With 50364 closed, this issue is clear now.Thnx!

But Acrobat still does not work as a plugin on Linux too. Is this true?

yes, acrobat does not work as a plugin on linux.

Putting [pdtp1] in whiteboard

Reassigning to Peterl.

I just tried the viewing a PDF file on the Mac as a plugin (attachment #1 [details] [diff] [review]) and except for the assertion, this seems to work. Not running Mozilla in the debugger will cause it to crash with a Type 12. The assertion is: ###!!! ASSERTION: null service manager: 'mServiceMgr != NULL', file ns4xPlugin.cpp, line 1061 Is there a particular reason why we are asserting a not null service manager when _useragent(NPP) is called since there is an IF statement which checking for this directly afterwards? Is there any harm in removing this to get PDF plug-ins to work?

adding av to cc since he put the assertion in. Andre, can you read my last comment, thanks.

mServiceManager is set in the constructor and then is used all over the place. So we shouldn't have it null. Why the assertion itself hurts? Is not it supposed to be doing nothing in the release build anyway?

per peter's comment, marking nsbeta3-. Apears to be wfm. Not holding pr3.

Adding rtm+.

Acrobat should always come up in the browser and not as a helper app, unless the user configures his system specifically to bring up Acrobat as a helper app. (There are numerous tech note on our web site that explain how to do this for each browser.) It sounds like there is a bug in the mac mozilla. (I have not tried that platform lately). The status of our plug-in working on Linux is unknown due to the requirement of moving to a different development environment (work that we have not done and will not be doing in the near term future).

Marking needinfo. Shrirang, could you look at this again to reconfirm the problem?

I just confirmed this with the mac m18 branch bits(20000929011). Acrobat still gets launched as a helper application rather than as a plugin within the browser. I have not explicitely specified it to launch as a helper app. This is stil a problem.I have resummarized this bug.Thanks

Andre, Looking deeper into nsPluginHostImpl:LoadPlugins(), I think the path to the layout library is not being retrieved correctly by SpecForRegistryLocation() therefore RegisterPluginMimeTypesWithLayout() never gets called. Part of this problem may be that PLUGIN_DLL is #defined as "PLUGIN_DLL" on the Mac instead of the proper name for that library like on other platforms. Question: Should PLUGIN_DLL be #defined as "pluginDebug.shlb"?

Changing from [rtm+ need info] to [rtm need info] per PDT system.

[rtm-]. Doesn't prevent user from accessing content; not an RTM stop-ship. According to peterl, user won't even realize something's wrong unless they're fairly savvy about how these things should work; from their perspective, Acrobat just starts up and runs in its own window. Nominating ns601 to restore consistency of behavior in the next release.

Not a Netscape 6 RTM blocker. FUTURE. This bug has been marked Future because the Netscape engineer it is assigned to is overburdened.

This is a Mac-only bug.

Setting mozilla0.8

Changing peterl-retired to peterlubczynski

Nom. nsbeta1 as this is a backward-compatibility bug for Acrobat and high-quality support for major plug-ins is a priority for embedding.

I've got this sort of working. Check out the patch in bug 62693: http://bugzilla.mozilla.org/showattachment.cgi?attach_id=25441

*** Bug 69403 has been marked as a duplicate of this bug. ***

Brian, My last patch almost fixes this bug (and makes full-page plugins on Mac work), however, I still have this one last crasher when going to Acrobat embedded prefs window, that I can't solve. Other windows work great. No stack. I've set breakpoints throughout plugins and I can't figure out what's causing the crash. In fact, the window appears, then then the crash. If you have a moment, could you possibly take a look at this? Oh, you need to link in the gfk library to compile. Thanks a LOT for your help!

I'm seeing the assertion failure of (mServiceMgr != NULL), but I'm not seeing a crash afterward. I have your testcase document open in another window as I write this. My only thought is that possibly the plug-in isn't expecting to get back a NULL value from _userangent? Maybe we should look into why a valid service manager wasn't passed in to the ns4xPlugin constructor?

Brian, It's the prefs panel which causes the crash. Here is a screen shot. Could you see if you can reproduce? changing testcase to one that works.

It's definitely crashing in the plug-in. That's going to make it hard for us to debug on our end. It seems like there might be some sort of context switching or "who's in control" issue going on. It looks like we hand the click on the menu popup control off to the plugin (in ns4xPluginInstance::HandleEvent().) I'm not real clear on this but, based on what I saw in the debugger, it appears that Acrobat is handling the control tracking even though the plug-in apparently returned control to Mozilla immediately. Selecting the menu item causes a switch to the Acrobat reader application to display the dialog. Returning from the dialog switches back to Mozilla. I hacked the following code in after the call to CallNPP_HandleEventProc. if (event->event->what == 1) { // mouseDown EventRecord theEvent; WaitNextEvent(everyEvent, &theEvent, 1, NULL); } This doesn't actually fix anything, but it does seem to make the problem somewhat less reproducible (at least for me.) I think it's giving the system time to allow Acrobat to grab control and do what it needs to do. This coupled with the fact that the plugin is crashing in QuickDraw calls, which is generally an indication of port related issues, make me think that we are fighting with the plugin over ownership of the current window/port/event queue/ something.

*** Bug 14496 has been marked as a duplicate of this bug. ***

I've applied the attached patch and with my plugin I get an assertion in nsView.cpp (nsView::GetViewFor - bad client data) and a subsequent unmapped memory exception. I don't have symbols at the point of the exception though - imagine it's the GetViewFor caller.

I think this is caused by the new view manager. I am getting that in recent builds but not ones from last week with the same patch. Try turing it off by: user_pref("nglayout.debug.enable_scary_view_manager", false); I'd like to check-in what I have so far and file bugs on the other issues as they arrise. Brian/Andrei/Chris Saari can I get reviews?

*** Bug 62693 has been marked as a duplicate of this bug. ***

Something has really changed in the past week. Builds from last week work great with my patch while new ones crash right before asserting in nsView about having a bad view. We shouldn't have bad views. In fact, there shouldn't be any views for full-page plugins, I think. They derive from nsIContentViewer. Turing off the new view manager does not help. Perhaps it's all the new XUL checkins as this worked before.

There was a crash in GetViewFor called by the new view manager, but I fixed it a few days ago. If you can get a backtrace, I can look into it further... Is this still happening only on Mac? For some reason I can't get the PDF plugin to work at all (won't come up in about:plugins).

Robert, Can you try this patch again (maybe re-install Acrobat) on Mac and perhaps super-review? I would like to get this out soon and file bugs for remaining issues as I am implementing full-page plugins for the first time on Mac.

I don't have a Mac ... sorry for any misunderstanding.

Ahh...with a recent update to the view tree and commenting out the assert on nsView.cpp line 207 my patch works great! Can I get some super-reviews?

Peter, the patch doesn't compile on Windows. The decl for GetPluginPort() is within a #define XP_MAC.

It looks as though GetPluginPort() is only called from #ifdef XP_MAC code. It seems that the function should be #ifdefed XP_MAC too.

The latest patch compiled on both win and mac, but something has changed recently and now I can't get a full page plugin to even load on mac - tried both Flash and Beatnik (see bug 47712). Can't test the patch anymore.

sr=attinasi - Peter, if all of that new code was taken from the ObjectFrame, does it make sense to factor it out into a common set of helper classes or methods?

Most, not ALL of the code was taken from nsObjectFrame. There were a few differences. It's actually the class nsPluginInstanceOwner defined BOTH in nsObjectFrame and nsPluginViewer (via case spelling) which should be factored out to it's own file. In the long term, I think that would be a good idea, Andrei? But, since this is the first implementation, I'd just like to get full-page plugins working first :)

I second this. a=av. We should probably file a bug on what Marc said, just not to loose it.

Filed bug 74457 on that issue.

Fix checked in. Markign FIXED. Please file seperate bugs on individual issues.

closing this one..verified on mac (with the workaround mentioned in bug 74926). VERIFIED