Got the same problem, any insights will be greatly appreciated.

Not exactly professional for me to tell thousands of clients (and potential clients) to check their acrobat settings.

Any workarounds? Can we code this straight from InDesign (my source application)?

By unprofessional, I meant to say that some users can access the links whilst others experience nothing. It would be unprofessional to have a disclaimer for users to check their security settings (not a valid work-around) or something like that.

I determined when this happens.

I have several forms that use "app.launcURL (...)", several years and just the installation of Adobe Reader X users have begun to have different problems.

Some say they are redirected to a page in Adobe, others just the browser opens but is blank, is not going to any page and in other cases non-existent open url like "http://xn--h5a9807h/" or "http://xn--tp-vxc5603s" ... Reader and all with X.

The problem is the length of the URL ... if it exceeds 255 characters failure occurs (which does not happen with earlier versions of Reader).

The following link will leave a form on which you can verify this:  http://www.nartexsoft.com/downloads_nartex/adobe/launchUrl-Issue.pdf

Greetings.    

We're having a similar problem.

First, an overview of our application. We have a (Java) web application where users can select documents to print. Upon a request, iText generates a PDF (displayed in the web browser with the Adobe Reader plug-in) with 1) an open action to print ("this.print(true);") and 2) a DID_PRINT action to redirect back to the application using launchURL ("app.launchURL();"). This all occurs in the same window; there are no pop-ups.

When we deployed the application, we were using Adobe Reader 9, and everything worked perfectly. Subsequently, we upgraded to X, and now this functionality works sporadically. Sometimes it works fine several times in a row, while other times it doesn't work several times, then suddenly does. Reloading the same PDF may change the behavior from broken to working or vice versa.

To verify this is an Adobe Reader issue and not an iText issue, I've saved off PDFs that initially exhibit the correct behavior. When loading those static PDFs, sometimes they work, and sometimes they don't. That is, the PDF doesn't change, but the behavior in the browser/plug-in does.

Some further notes:

- It seems that launchURL() never works in IE when loading a PDF from the local filesystem. In addition, it seems that if it is working (via a PDF from the server), opening a PDF from the local filesystem in another tab stops it from working in all tabs.

- For debugging purposes, I've tried replacing launchURL() with alert(). From what I can see, this always works, regardless of where the PDF resides. This, in addition to the fact that the initial printing (this.print(true)) always works indicates that JavaScript is not being blocked in general (regarding the Protected Mode/JS disabled reference in this thread).

- As far as I can see, launchURL() always works correctly in Firefox, even from the local filesystem. Unfortunately, our users only have IE on their PCs.

I'm hedging a bit above ("It seems") as, because of the sporadic nature of this, it is hard to say for certain what always/never works and what usually/rarely works.

Any ideas? The random nature of this has made it very frustrating to diagnose. Some sort of security setting comes to mind, but one would assume the behavior would be consistent. That is, if a policy was blocking launchURL(), it should always block it, which isn't the case.

Version details:

IE 8.0.6001.18702CO

Adobe Reader plug-in: 10.0.1.434

Firefox 3.6.28

Adobe Reader plug-in: 10.0.1.434

FYI, I updated to Adobe Reader 10.1.4.38, and the behavior is the same. That is, in IE sometimes launchURL() works, sometimes it doesn't.

Anyone?

"Enable Protected Mode at startup" is greyed out for me. It doesn't appear to be checked, but I'm not sure how to confirm that.

Nevertheless, even if it is enabled, it doesn't make sense that sometimes it would work and sometimes it wouldn't.