How to make JavaScript debugger in Designer work again

LC_bugIf you find that you can not debug your form JavaScript from within Designer, there is a good chance that Acrobat Pro is not configured correctly for debugging.

LiveCycle Designer attempts to preview PDFs by hooking into the current Adobe ActiveX Control add-on that is enabled inside Internet Explorer. This can be either Adobe Reader or Acrobat Pro. Acrobat Pro is required if you want to debug your JavaScript from within Designer. If you never see the Preview PDF option in Designer or it is greyed out, then try enabling the Adobe PDF Reader add-on within IE.

My problem was that I could not debug JavaScript from within Designer natively. Every time I tried to Preview certain PDFs, Designer would hang and FormDesigner.exe was left running when I closed Designer.

After many hours of hair pulling, uninstalling and re-installing Workbench, Designer, Acrobat (argh!) and generally going in circles I found that only forms that contained the FormBridge XFO were failing. Form Bridge is a JavaScript “bridge” library used to communicate externally with Workspace or Flex applications (Guides). It adds a script object to the hierarchy called ContainerFoundation_JS. When Preview PDF was invoked from Designer with this script added to the form, it would lock up.

The fix

It seems that if you set your JavaScript preferences in Acrobat Pro to Break when an exception is thrown – you’re gonna have a bad time…

Only use the Ignore or Trace settings, never Break as this actually breaks. Breaks Designer.

Acrobat Pro Preferences

Clean up after yourself

During this process and having to re-install everything multiple times, I was pointed in the direction of the Acrobat and Reader cleaner. Not to be confused with the Creative Cloud cleaner. The fact that any software requires a cleaner tool and doesn’t automatically clean up after itself both on installation and un-installation is a rant I choose not to go into right now for pure sanity reasons. Also be aware that the cleaner tool does not clean everything. I found remnants of Acrobat in my roaming profile under Windows 7 that even I could not delete and I was the local Administrator. </mini-rant>


About Darren
I am a Senior Consultant and for BizTECH Enterprise Services (Australia) specialising in AEM Forms and Adobe LiveCycle, Document Services and Adobe Experience Manager.

5 Responses to How to make JavaScript debugger in Designer work again

  1. dave says:

    a-ha! so it seems that PDF Preview is actually running an instance of my browser? this might explain why when testing my Submit button on my reader extended form to submit to my java servlet it needs to authenticate first…but in Reader, my form stops short during submit process: “The server has an invalid SSL certificate” [Reader XI + websphere 7.0]

    • Darren says:

      Hi Dave – I don’t purport to being an expert on how Adobe wired all this black magic together. All I know is that finding the answers to some of these questions is very difficult as there are very few people in Adobe who really know how it all works any more. I have requested many times (actually directly with one of the Designer lead developers himself this year!) that Designer provide us with some debugging information so we, as developers, can understand why their stuff breaks all the time. It seems that this is way too hard a concept for them to do so we can only guess as to why it is so temperamental.

      But to answer your question – standalone Reader will have extra security around your form if is not running as a plugin in the browser. If your form is being served up in the browser from the same domain as the submit servlet, then you wont typically have any authentication issues. It will fail from standalone Reader though as it is not running in the same domain anymore and will require authentication.

      • dave says:

        well this is unexpected (i am new to LC, but not SW dev): are you saying when i serve the form in the browser — response.setHeader(“Content-Disposition”, “inline”) — that’s the only way to obtain trust between form & server? Because when i do that, it appears my reader extensions are removed (i.e., i no longer see “Extended” like i do when serving the form to Reader — response.setHeader(“Content-Disposition”, “attachment;filename=foo.pdf”). What you wrote does make sense, however, if i think of the standalone form as a long lived process.

        forgive my ignorance, but i made the assumption that serving a form to be filled & submitted over https was being done since time immemorial. maybe my architecture is wrong? would a bottom-up bean-driven web service be my only option? hope not, as i know even less about that (but i guess i’d have to put on my big boy pants, if needed).

        our company is an adobe partner, but they still want consult fees for what i thought were trivial questions, and we’re a little thin on funds. and of course, search engines are also thin on useful details. thanks for the speedy reply.

      • Darren says:

        Hi Dave – your form definitely needs to be reader extended if you are submitting to a servlet from outside the browser in Adobe Reader. It will still ask you some security trust questions and the like, but it should submit provided the endpoint you are submitting to is accessible externally.

        If you are serving the form up from Livecycle via the browser and the submission servlet is hosted within the same domain (inside Livecycle/WebSphere is the best option), then you can usually forgo the reader extensions as the Reader plugin is trusted for that domain. Bear in mind that saving the form and attempting to use it in Adobe Reader outside the browser will then no longer work.

        If you are still having issues, I suggest heading over to the Livecycle Google Group and posting up your queries there. Plenty of knowledgeable peeps there!!forum/livecycle

      • dave says:

        thanks, mate!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s


Everything AEM aka CQ5 based on my experience listed here.

Adobe AEM The Right Way

Best practices, tips, and tricks for your Adobe AEM project


A WCM journey with Day/Adobe CQ

Technoracle (a.k.a. "Duane's World")

A multi-purpose toolkit for the Adobe LiveCycle and AEM Forms developer.

Adobe LiveCycle Blog

A multi-purpose toolkit for the Adobe LiveCycle and AEM Forms developer.

A multi-purpose toolkit for the Adobe LiveCycle and AEM Forms developer.


A multi-purpose toolkit for the Adobe LiveCycle and AEM Forms developer.

Code Monkey

Ramblings of a Developer

%d bloggers like this: