The first test button on the HTML to FDF page, "Returns FDF that specifies a PDF" freezes or crashes Mozilla 2002042403 on OS X. This test succeeds on both Mac IE for OS X and on the AOL beta X27A. I suspect that the problem might be related to our use of the ThreadManager as a scheduling mechanism to give Acrobat time to execute. The crash actually occurs because Acrobat throws an exception, I believe because it is not getting a response back from the browser.

on windows, I get an "Open with AcroExch" dialog and then nothing happens? John, can u confirm this pls?

no crash for me on my mac OS 9.2.1 with 0426 branch . Instead of opening in the same browser frame, a new browser window opens up and loads the pdf just fine, no crash. I do not have the acrobat plugin to test this os OS X. works definitely on OS 9.

The trunk build for today (windows version) works because of bug 133751 being fixed. Make sure you have Acrobat 5.05 installed

I haven't tested on OS 9 for a while, but it did work for me back when I did. Peter Lubczynski should still have an OS X plugin.

Is this a new problem? For those behind the Netscape firewall, you can find the OSX Acrobat plugin that John sent to me in my home directory: http://warp.mcom.com/u/peterlubczynski/AcrobatOSX/PDFViewerOSX.img

Here is the scoop with this bug: we are finally far enough along with Acrobat "in the browser" on OS X to fully test each OS X browser (test each piece of Acrobat browser functionality, including the many tiny details associated with Acrobat forms). During this testing, we discovered that this functionality is broken in the OS X version. John Kinder believes it is related to the the fact that we need to use cooperative threads in the Acrobat Browser plug-in, and we therefore need the browser itself to support cooperative threads.

setting to 1.1

Liz/John, I asked Patrick Beard if we support cooperative threads and here's his response: No, we are using our own hand-rolled cooperative threads. They are probably using the thread manager threads, which aren't exactly compatible with our threads. It's a pain. What I recommend people do is synchronize with us by using carbon timers, which will allow them to get a call back on our main thread. I'm using this technique in the Mac OS X Java plugin. Some sample code is here: http://lxr.mozilla.org/mozilla/source/plugin/oji/MRJCarbon/plugin/Source/MRJContext.cp#994

We already use a carbon timer to get time for our thread, that worked in most instances. I was speculating about it being a thread issue here, because this test does work in the other major browsers (including AOL and Compuserve). It could be that some other change in the AOL environment allows this test case to work there but not in Mozilla/Netscape.

Looking at this problem some more, it appears that it's not a thread problem. In Thread Viewer, both the Acrobat thread and the main thread are getting time, and when I paused Mozilla, the main thread was always in Mozilla code. What we've seen is that we request Mozilla to download a PDF, the file gets transferred over the wire, but the bytes never get sent on to PDFViewer/Acrobat. We've hit a wall in debugging this, and would love it if you can give us some information about what's happening on your end.

A few more details on this. It is different from the case of hitting just a PDF file in an HTML link, and also it is different on OS X than on any other platform. 1 - Acrobat is registered as a plugin for PDF and FDF (versus just PDF). 2 - In this case, first there is a plug-in instance opened for some FDF that is downloaded and handed off to our plug-in. 3 - Then Acrobat turns around and asks for a PDF file (through NPP_GetURL, I believe). 4 - Then the server downloads the PDF .. .which we expect to be handed off to us. The bug is we see the PDF coming down the wire ... but it is never handed off. Also, this test case works in OS X Mac IE. Oh, and we can wait until after your current beta crunch for this. Thanks.

There has been a few bug fixes to network streams that may effect this bug. John, can you retest this with a newer build like perhaps one of these: http://ftp.mozilla.org/pub/mozilla/nightly/2002-08-19-05-1.0/ Also our QA has asked to test the new Acrobat on other AOL products. The drop I have is from April. Are there newer bits?

Having the same problem on WinNT Workstation with mozilla 1.3a downloaded today, 12/16/2002. Plugin List shows Acrobat version 5.10 for Netscape. Mozilla freezes and requires "End Task". Repeatable every time (4 attempts).

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030210 With Acrobat plugin (either v4.05 or v5.0), the first PDF document displays fine. However, if you hit "Back" or close the tab/window which previously had a PDF file in it, all following PDF files will hang in the browser trying to load. Occasionally you can hit <Esc> to abort the PDF page load and continue browsing as normal, but if you want to display other PDF files the only fix is to restart the browser.

I get a similar effect downloading pdfs. I use Firefox 2.0 on a Mac Powerboook 1Ghz PPC G4 CPU with 1.5GB DDR SDRAM running Os X10.4.8 My 'broadband' account is a fossilized 512k. If I download using the pdf link on http://www.genetics.org/cgi/content/full/172/1/445 I get the spinning pizza for 4-5 min while the download happens. If I do the same using Safari, the pdf appears on the webpage in half the time, without the spinning pizza. So at least I can open another page and do something in Safari while I am waiting. What I would really like to do in Firefox is download without the holdup, and be able to rename the file and place it in a directory of my choice (different for each file).

is this problem gone? I don't see anything of value in this bug as *none* of the reference URLs work.

do you see any sign of this?

You can close this bug. At this point, we do not support Firefox on the Mac with the Adobe Reader. Once there is a cocoa Firefox, we will reevaluate this. I will add Rudi Sherry to the cc: List since he owns the Mac Reader browser integration.

(In reply to comment #18) > You can close this bug. At this point, we do not support Firefox on the Mac > with the Adobe Reader. Once there is a cocoa Firefox, we will reevaluate this. > I will add Rudi Sherry to the cc: List since he owns the Mac Reader browser > integration. > Unless you meant 'pure' cocoa (no XUL), Firefox trunk have switched from carbon to cocoa toolkit.

FYI, this bug affected both PC and Mac platforms. However in the 3 years of inactivity on this bug ID the issue appears to be resolved at this time.

--> WFM per above