581472 - Inline 32bit Acrobat Reader Fails After Multiple PDF Viewings

Status: RESOLVED INVALID

(Core Graveyard :: Plug-ins, defect)

Description

[drichard]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:2.0b1) Gecko/20100630 Firefox/4.0b1
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:2.0b1) Gecko/20100630 Firefox/4.0b1

Unfortunately, Acrobat still makes us run the 32bit version of Reader for inline PDF viewing.  I installed it using nspluginwrapper and the first few that are viewed work correctly.  Then after around 3-4 PDFs it fails and the screen just turns white and the plugin never loads.  Running it from the command line does create some spewage which I hunted and it appears to be coming from Firefox:


###!!! [Child][RPCChannel] Error: Route error: message sent to unknown actor ID


When I close and re-open FF it works correctly again for a few documents and then fails.

Caveats of my testing:
- Firefox is being run over remote display (X)
- Firefox is running in 16bit color.

Reproducible: Always

Steps to Reproduce:
1. Install 32bit Acrobat Reader with nsplugin wrapper
2. View several PDF documents
3. After a few of them the plugin will fail to load and you just get a white empty canvas

Comment 1

[drichard]

Attachment: PDF loads, canvas is empty after working initially

Comment 2

[Benjamin Smedberg]

This is probably a duplicate of bug 583576, which we have fixed in the 1.9.2 branch. Can you try a branch nightly from here and let me know whether you can still reproduce this bug?

http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-1.9.2/

Comment 3

[Benjamin Smedberg]

Hrm, actually it might not be related at all. This was reported against OOPP on trunk.

Comment 4

[drichard]

Tested with Reader 9.40 + Beta 6 and issue remains.  This is a showstopper for our deployment (800 users).  Our county Government website is hard coded to only work with inline PDF documents, and we cannot use Reader as an external application.    If there is anything I can do to help, just let me know.

Comment 5

[Benjamin Smedberg]

Have you got a particular PDF or URL that this happens on, which we can test with? Unless we're able to reproduce this, there's probably not a lot we can go on here.

Comment 6

[drichard]

@benjamin:  Sure thing, my test link is:

http://www.largo.com/egov/docs/1285962790938.htm

On a fresh launch of FF, I was able to click on #1, #2, #3 and #4.  When I clicked on #6 the canvas turned black, and then after a few seconds it turned white.  I believe this is an indication that the document has downloaded and should then be displaying.  I'll attach an image, marking in green the 4 that worked and then failure marked in red.

Just to clarify how we run it, it's running 16bit color over remote display from a server.  The contents of the plugin directory is below.  Acrobat Reader is the only 32bit plugin that remains, everything else is now running natively in 64bit.



-rwxr-xr-x  1 root root   315684 Sep 28 15:46 gecko-mediaplayer-dvx.so
-rwxr-xr-x  1 root root   315683 Sep 28 15:46 gecko-mediaplayer-qt.so
-rwxr-xr-x  1 root root   315683 Sep 28 15:46 gecko-mediaplayer-rm.so
-rwxr-xr-x  1 root root   315684 Sep 28 15:46 gecko-mediaplayer-wmp.so
-rwxr-xr-x  1 root root   319868 Sep 28 15:46 gecko-mediaplayer.so
-rw-r--r--  1 root root 10597872 Sep 28 15:43 libflashplayer.so
lrwxrwxrwx  1 root root       61 Sep 20 10:43 libnpjp2.so -> /usr/lib64/jvm/java-1.6.0-sun-1.6.0/jre/lib/amd64/libnpjp2.so
-rwxr-xr-x  1 root root   134648 Oct  6 12:18 npwrapper.nppdf.so
-rwxr-xr-x  1 root root   134648 Jul 19 10:39 npwrapper.so

Comment 7

[drichard]

Attachment: Green links worked, failure on link marked in red. The first several always work.

Comment 8

[Benjamin Smedberg]

Debugging acrobat loading via nspluginwrapper on Linux is probably not a high priority for us at this point, I'm sorry to say.

Comment 9

[drichard]

This is so old, no reason to keep it open.   PDFs are displayed via JS now in FF.