Using the Acrobat JavaScript Debugger with XFA

Many of you are already aware that the JavaScript debugger inside Acrobat partially works with XFA forms.  You can turn on the debugger in the Acrobat preferences:

image

When debugging is turned on, the Acrobat JavaScript console will allow you to navigate to objects in the XFA hierarchy and set break points in a subset of events:

 image

BUT (and you knew there was a "but" coming) there are some serious limits:

  • Using the debugger with XFA forms is not officially supported
  • We cannot debug script objects
  • Storing break points doesn’t seem to work.  This makes it hard to debug an initialization script (unless you force your form to do an xfa.form.remerge())

On the other hand, even with these limits, many of you will find the debugger useful.

There’s another "but" and this is really my main reason for posting on this topic. 
You need to turn off the debugger when you’re not using it.

There are two reasons:

Exception handling.  Note the first dialog above has the option to break when an exception is thrown.  If you’re not expecting it, this option can circumvent normal JavaScript processing.  e.g. it is good JavaScript practise to use try/catch to quietly handle error conditions.  With try/catch we can detect an error condition and allow the application to continue uninterrupted.  But when the debugger has been told to break on exceptions, the quiet thing doesn’t happen any more.  The form stops and you get a message to the console.

Performance.  Do you remember the game of life form? I used it to illustrate some performance characteristics in this blog entry.  The form has a couple of buttons with around 30,000 lines of JavaScript in their click event.  Under normal circumstances, these scripts finished in between 4 and 10 seconds.  With the JavaScript debugger enabled, these took … 10 minutes.  That’s right, roughly a 50 times slow down in script performance with the debugger enabled.

The Inevitable Question

When will XFA have proper JavaScript debugging support?  This is a hard question to answer.  But it gets asked a lot.  Believe me when I say that  we’ve taken a run at this problem many times in the past.  But the fact remains that there are some substantial technical barriers that are holding us back.