Closed Bug 35682 Opened 24 years ago Closed 24 years ago

Acrobat does not launch as a plugin and launches as a helper app even if not explicitly specified

Categories

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

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

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla0.9

People

(Reporter: shrir, Assigned: peterlubczynski-bugs)

References

(
URL
)

Details

Attachments

(5 files)

testcase with a PDF used as a plugin
239 bytes, text/html
Details
new testcae, oroginal file not in existence on server
185 bytes, text/html
Details
patch from bug 62693 to almost fix this
14.07 KB, patch
Details | Diff | Splinter Review
screen shot of where prefs are in Acrobat full-screen
11.88 KB, image/jpeg
Details
better patch (#2) please try this (remember to link in gfk)
15.70 KB, patch
Details | Diff | Splinter Review 
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.
Keywords: crash
Marking acrobat. Nom. nsbeta3, recc. nsbeta3 stopper. Acrobat is #2 most popular 
plug-in per HotBot; don't want it to crash.
Keywords: acrobat, nsbeta3
Keywords: 4xp
Shrirang, would you try this with our recent changes?
Status: NEW → ASSIGNED
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?
Keywords: crash
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.
Summary: Crash trying to view pdf file on mac → Cannot view pdf files on mac, acrobat reader does not launch
Whiteboard: [nsbeta3+]
Note: working fine on linux m17 build 2000080414.
Priority: P3 → P1
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.
OS: Mac System 9.0 → All
Putting [pdtp1] in whiteboard
Whiteboard: [nsbeta3+] → [nsbeta3+][pdtp1]
Reassigning to Peterl.
Assignee: av → peterl
Status: ASSIGNED → NEW
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?
Status: NEW → ASSIGNED
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.
Whiteboard: [nsbeta3+][pdtp1] → [nsbeta3-][pdtp1]
Keywords: rtm
Whiteboard: [nsbeta3-][pdtp1] → [nsbeta3-][pdtp1] [rtm+]
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?
Whiteboard: [nsbeta3-][pdtp1] [rtm+] → [nsbeta3-][pdtp1] [rtm+ needinfo]
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
Summary: Cannot view pdf files on mac, acrobat reader does not launch → Acrobat does not launch as a plugin and launches as a helper app even if not explicitely specified
Whiteboard: [nsbeta3-][pdtp1] [rtm+ needinfo] → [nsbeta3-][pdtp1] [rtm+ need info]
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"?
Summary: Acrobat does not launch as a plugin and launches as a helper app even if not explicitely specified → Acrobat does not launch as a plugin and launches as a helper app even if not explicitly specified
Changing from [rtm+ need info] to [rtm need info] per PDT system.
Whiteboard: [nsbeta3-][pdtp1] [rtm+ need info] → [nsbeta3-][pdtp1] [rtm need info]
[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.
Keywords: ns601
Whiteboard: [nsbeta3-][pdtp1] [rtm need info] → [nsbeta3-][pdtp1] [rtm-]
Not a Netscape 6 RTM blocker. FUTURE. This bug has been marked Future because
the Netscape engineer it is assigned to is overburdened.
Target Milestone: --- → Future
Keywords: ns601 → mozilla0.9
Depends on: 47712
This is a Mac-only bug.
Hardware: PC → Macintosh
Depends on: 62693
No longer depends on: 62693
Depends on: 62693
Setting mozilla0.8
Target Milestone: Future → mozilla0.8
Changing peterl-retired to peterlubczynski
Assignee: peterl-retired → peterlubczynski
Status: ASSIGNED → NEW
Nom. nsbeta1 as this is a backward-compatibility bug for Acrobat and
high-quality support for major plug-ins is a priority for embedding.
Keywords: nsbeta1
Target Milestone: mozilla0.8 → mozilla0.9
Status: NEW → ASSIGNED
I've got this sort of working. Check out the patch in bug 62693:

http://bugzilla.mozilla.org/showattachment.cgi?attach_id=25441
Keywords: nsbeta1, nsbeta3, rtm
Whiteboard: [nsbeta3-][pdtp1] [rtm-]
Depends on: 70346
*** 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.
URL: http://access.adobe.com/cookbook.pdf → http://www.adobe.com/support/pdfs/chg...
Keywords: patch
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?
Whiteboard: [seeking review]
No longer depends on: 62693
*** 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.
No longer depends on: 47712
Whiteboard: [seeking review]
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.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
closing this one..verified on mac (with the workaround mentioned in bug 74926). 
VERIFIED
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: