18679 - [ACROBAT][DOGFOOD][BETA] Adobe Acrobat Plug-in Crashes M10 Build

Status: VERIFIED FIXED

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

Description

[lmcquarr]

Andrew Volkov asked plug-in developers to test plug-ins with the latest build.
I am the engineer who owns browser integration in Adobe Acrobat Engineering ...
so I tried our Netscape plug-in (nppdf32.dll) with the M10 build, and then
viewed the above URL ... and CRASH.  Note that the basic functionality
used to work in M8, but byte serving did not work in that release.

Here is how to reproduce:

1 - Go get the latest Acrobat reader from http://www.adobe.com.

2 - Copy the nppdf32.dll file from the install directory of Acrobat
(in the browser subdirectory) to your plug-ins directory.

3 - Start apprunner and then go to the above URL.

4 - You should crash.

Please note that I am very happy to provide the source code and project
files for the Acrobat Netscape plug-in.  THere is nothing proprietary
in them and I have already given them to both Netscape and Sun.

Please also note that the Acrobat team played a significant role in
the development of the Netscape plug-in interface, way back in
95.  We are quite aware of some poorly documented and ambiguous
features in the API and we are concerned that the implementation
in mozilla is a 100% rewrite.  YIKES!

I will be very happy to do a whole lot more testing once we
get past this crasher.

Comment 1

[lmcquarr]

Here is the call stack:

RAPTORPLUGIN! 60a8182b()
RAPTORHTML! 604247f5()
RAPTORWEB! 60a92758()
RAPTORWEB! 60a92bfc()
NECKO_HTTP! 60353fc9()
NECKO! 602f86ad()

Comment 2

[lmcquarr]

I put the Acrobat Netscape plug-in in a debugger and set a breakpoint
at every NPP_* call.  Our plug_in gets called with:

NPP_Initialize
NPP_New
NPP_SetWindow

And then we crash.

We never get to NPP_NewStream, which would be the next NPP_ call that
we would expect.

Comment 3

[lmcquarr]

I have set up a number of PDF file for testing on a server outside
of our firewall:

I have set up a number of test files for  you.


Basic tests to do are:

1 - Open the file.
2 - Page through a few pages.
3 - Jump to the last page by pulling down the scroll bar.
4 - Use any links that are available.
5 - Use any bookmarks or thumbnails that are available.

This set of test files just have various numbers of pages to play with
and some include a lot of link annotations:

http://access.adobe.com/browser/fibroch.pdf
http://access.adobe.com/browser/pcweek.pdf
http://access.adobe.com/browser/starr.pdf (Ken Starr Report :-)
http://access.adobe.com/browser/wharton.pdf
http://access.adobe.com/browser/icnews.pdf
http://access.adobe.com/browser/intel.pdf
http://access.adobe.com/browser/simple1.pdf
http://access.adobe.com/browser/simple4.pdf

These contain bookmarks and are fairly long:
http://access.adobe.com/browser/acro4faq.pdf
http://access.adobe.com/browser/pdfref.pdf

This contains thumbnails:
http://access.adobe.com/browser/thumbs.pdf

This is an active Acrobat Forms demo:
(this will only work if you have implemented the NPN_PostURL method ...)

http://access.adobe.com/browser/formsdemo.pdf


Let me know if you need more help!

Comment 4

[Eli Goldberg]

lmcquarr: wow; talk about testing resources, thank you!



(ekrock is the developer relations contact for plug-ins, in case you haven't

already spoke with him.)



---



av: using a more current (1999111108) build on NT 4.0 SP5, I'm not seeing an

actual hard crash, but the application is totally frozen (doesn't respond to

events) after the Acrobat reader is invoked.

Comment 5

[lmcquarr]

Since the latest build produces a frozen Acrobat, it probably would be
useful if I can help debug. It looks like I need to get CVS up and running to
get the latest build, which will require my IS department to punch
a hole in our firewall for me to use for this purpose ... so it may be a
few days before I can get myself to a point where I can help further.

Comment 6

[lmcquarr]

AHHH.  I didn't release that the FTP drops are daily!  I guess I don't have
to wait for the firewall hole to run CVS to pursue this further.

I just the the ftp drop from today and all of the build tools and am
now building, so hopefully early next week I can explore the hanging
in Acrobat issue and let you all know what it looks like from
the inside of our code  (my suspicion is that we asked for some bytes
and mozilla didn't give them to us .. and now we wait in a five minute
timerloop waiting for them to arrive ... before we time out).

Comment 7

[Eli Goldberg]

Thank you! Please let me know if I can be of any help.

Comment 8

[ekrock's old account (dead)]

You say that in your test procedure you manually moved the Acrobat plug-in DLL
nppdf32.dll into the AppRunner plugins directory. Question: what happens if you
instead install Nav4, install Acrobat into Nav4, make sure Acrobat's working in
Nav4, then install AppRunner and test the same file using AppRunner? This is I
believe the currently approved procedure for testing plug-ins in AppRunner as
AppRunner automatically looks in the Nav4 plug-ins directory to find
already-installed plug-in binaries.  Please give that a shot and see if the
results are the same. Want to make sure your bug isn't an artifact of the manual
by-hand file-copy install. Thanks!

Comment 9

[ekrock's old account (dead)]

Marked [ACROBAT] to enable easy searching. For ease of searching/tracking by
plug-in, let's label all plug-in API bugs that are specific to a particular
plug-in (such as [ACROBAT]) with the name of the plug-in in brackets (in this
case, [ACROBAT]).

Comment 10

[av (gone)]

Looks like a parser problem. Sending to harishd for investigation.

Comment 11

[lmcquarr]

As suggested, I removed the nppdf32.dll plug-in from the apprunner plug-ins
directory, and allowed Mozilla to find nppdf32.dll in the plug-ins directory
of Navigator 4.  The result:  Apprunner still blows up.

Comment 12

[harishd]

The problem is not in parser after all.  However, an error in the parser was
blocking av to probe into the actual problem.  Have suggested a patch to av.

Reassigning to [e-mail]

Comment 13

[Judson Valeski]

Do pdf files work in general and this one is aggrivating a problem? Any ETA if
pdf's are broken in general? A milestone would be nice here :).

Comment 14

[lmcquarr]

PDFs do not work at all.  I would love to get beyond this point so that
I can do further testing.   PDF/Acrobat is one of the few plug-in  that
exercises byte range requests.  Acrobat also exercises some poorly documented
features of the Netscape API.  That is why I am anxious to get beyond this point
where nothing works at all to see what else is broken.

As soon as there is a "heart beat" with basic PDF viewing, I will be very
happy to continue testing.

Comment 15

[lmcquarr]

BTW -- there are more than 2.3 million PDF files on the web right now.

Comment 16

[Paul MacQuiddy]

Probably not dogfood, but marking as such for consideration.

Comment 17

[rickg]

If the fix comes in today, we'll take the fix. Otherwise we're marking this
[beta] but not dogfood.

Comment 18

[leger]

Putting on BETA radar.

Comment 19

[lmcquarr]

Greetings.  Eric Krock sent out a message yesterday reiterating that
a goal for Mozilla was a 100% backward compatible API.

Let me suggest to you that a good way to ensure that goal is to work with
me to get Acrobat fully functional in Mozilla.  In case you are not
aware, Acrobat is the one plug-in that exercises probably 99.9% of
the NS API functionality.  This is because back in 1995,
Acrobat Engineers worked very closely with Netscape engineers to
design the plug-in interface, since Adobe has many years
of plug-in interface experience behind it.  Most of the design came
out of a discussion of how to integrate the two products (Navigator
and Acrobat.)

Having said that, I have test cases in Adobe for exercising every aspect
of browser/Acrobat integration, from byte range requests to Acrobat
forms posting.  As I have done with another browser company implementing the
Netscape API, I would be very happy to test all of these cases and
provide explicit and detailed bug reports (listing expecting behavior with
reproducible test cases on an external server).  I worked with this
other browser company in a very iterative fashion to help them, and I am
very happy to help you (and obviously, that helps Acrobat too).

I am fairly confident that if we can get mozilla to be an excellent
browser platform for Acrobat, you will have achieved very close
to 100% backwards compatibility.

Note: At this point, however, because of this bug, I am completely blocked
on doing any further testing.

Comment 20

[shrirang khanzode]

With build 1999122023 on windows, I can see that Acrobat Reader opens up when I
click on the pdf links given in this bug. But the Reader does not display the
file contents. And there is no crash. :-)

Comment 21

[av (gone)]

I get a debug asserion in doing EndDocument event in
nsWalletlibService::OnEndDocumentLoad in this chunk of code:

nsCOMPtr<nsIContentViewer> cv;
rv = ws->GetContentViewer(getter_AddRefs(cv));
if (NS_FAILED(rv) || (cv == nsnull)) {
return rv;
}
nsCOMPtr<nsIDocumentViewer> docViewer(do_QueryInterface(cv));
NS_ENSURE_TRUE(docViewer, NS_ERROR_FAILURE); -- fails here

Here is the stack trace:

NTDLL! 77f76148()
nsDebug::Assertion(const char * 0x0223b5f0, const char * 0x0223b5e4, const char
* 0x0223b5ac, int 237) line 186 + 13 bytes
nsDebug::WarnIfFalse(const char * 0x0223b5f0, const char * 0x0223b5e4, const
char * 0x0223b5ac, int 237) line 242 + 21 bytes
nsWalletlibService::OnEndDocumentLoad(nsWalletlibService * const 0x0275577c,
nsIDocumentLoader * 0x08084f00, nsIChannel *
0x0851cf50, unsigned int 0, nsIDocumentLoaderObserver * 0x0275577c) line 237 +
38 bytes
nsDocLoaderImpl::FireOnEndDocumentLoad(nsDocLoaderImpl * 0x08084f00, nsIChannel
* 0x0851cf50, unsigned int 0) line 1104
nsDocLoaderImpl::FireOnEndDocumentLoad(nsDocLoaderImpl * 0x08084f00, nsIChannel
* 0x0851cf50, unsigned int 0) line 1112
nsDocLoaderImpl::FireOnEndDocumentLoad(nsDocLoaderImpl * 0x08084f00, nsIChannel
* 0x0851cf50, unsigned int 0) line 1112
nsDocLoaderImpl::DocLoaderIsEmpty(unsigned int 0) line 995
nsDocLoaderImpl::OnStopRequest(nsDocLoaderImpl * const 0x08084f04, nsIChannel *
0x0851cf50, nsISupports * 0x00000000,
unsigned int 0, const unsigned short * 0x00000000) line 920
nsLoadGroup::RemoveChannel(nsLoadGroup * const 0x08084ea0, nsIChannel *
0x0851cf50, nsISupports * 0x00000000, unsigned int
0, const unsigned short * 0x00000000) line 531 + 42 bytes
nsHTTPChannel::ResponseCompleted(nsIChannel * 0x084f2030, nsIStreamListener *
0x084d73f0, unsigned int 0, const unsigned short
* 0x00000000) line 1306
nsHTTPResponseListener::OnStopRequest(nsHTTPResponseListener * const 0x084f4bc0,
nsIChannel * 0x084f2030, nsISupports *
0x0851cf50, unsigned int 0, const unsigned short * 0x00000000) line 253
nsOnStopRequestEvent::HandleEvent(nsOnStopRequestEvent * const 0x084df3c0) line
279
nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x084df370) line 93 + 12 bytes
PL_HandleEvent(PLEvent * 0x084df370) line 522 + 10 bytes

Comment 22

[av (gone)]

Adding people whose opinion could be of great help. Could you please have a
look?

Comment 23

[Stephen P. Morse]

Well this is my piece of code alright.  But I don't know what it means that I
was passed in a null docViewer.  Is that an error upstream from me?  Or is it a
perfectly normal situation but one for which my code should have no interest in?
If the latter, then I should remove the assertion with a test and bail out if
it's null.

Did this assertion failure just start happening?  If you resume from this
failure what happens?  Can you try making the change I just suggested and see if
that fixes the problem?

Comment 24

[av (gone)]

Right, it could be normal situation, it doesn't crash any longer.

The content is not displayed. The reason for that is that the plugin does not
process the data passed via NPP_Write call but rather waits for the data cache
file and accordingly NPP_StreamAsFile call which never happens. I contacted
gagan who is the owner of the network cache module.

lmcquarr, please confirm that I am looking in right direction.

Comment 25

[lmcquarr]

HMMMMM.   I am not sure you are going in the right direction.

The Acrobat plug-in to Netscape uses both the NPP_Write call and the
NPP_SteamAsFile call, depending on the context (and the bugs in Navigator
that we are trying to work around :-).  Our NPP_NewStream call, where
we are given the opportunity to say whether we want a seekable stream
or the stream as a file, has a lot of code to check Netscape version
numbers, whether the file being opened is a local file, whether the
file is from a secure server, whether the file size is bigger than
the cache size, (etc!), before it decides to as for the stream
as a file, rather than a seekable stream, which we prefer.

Most of the time, we want the data to come via NPP_Write (NP_SEEK).
In specific cases, usually for bug work arounds or for Acrobat forms
posting, we ask for the stream as a file (NP_ASFILE).

If you can tell me the specific steps you are doing, I can tell you
what code path we are going down.  OR better yet, I am able to provide
to you the source code and project files to the Acrobat plug-in to
Navigator.  Let me know if you are interested (I have given them
to Sun already).

Comment 26

[av (gone)]

OK, the story looks as follows. The mechanism which allows to find out if the
http server supports byte ranges is still to be implemented in netlib. Till now
every new stream has been specified as not seekable. I change it to be seekable
to make Acrobat work and unblock Adobe people. Meanwhile, I am going to file a
bug against netlib (or find existing one) so that to be notified when it is
ready (and disk cache too) and add the appropriate logic to the code.

Marking this one fixed.

Comment 27

[shrirang khanzode]

Verified with commercial build on Windows (2000012520M13). Marking as such.