Skip to main content
sberic
sberic
Legend
April 12, 2019
Question

ExtendScript Debugger v1.x Needs a Rethink

  • April 12, 2019
  • 1 reply
  • 7706 views

[This was originally posted in another private forum here. Moved to this forum for more open discussion and link-ability.]

 

TL;DR

The ExtendScript Debugger has some serious problems that stem from its current implementation. In summation, the debugger does not work like other debuggers in VSCode (e.g. NodeJS) [or any other mainline IDE debugger (that I'm aware of)], which is the default expectation for any user. Specifically this means:

 

  1. The debugging session appears to stop immediately after being run.
  2. Compound Launch Configurations cannot be used.
  3. VSCode Breakpoints do not work unless very specific, non-obvious configuration settings are in place.
  4. VSCode Breakpoints might mysteriously fail to work, even with the non-obvious configuration settings in place.

 

All of the above issues are related to the current way that the ExtendScript Debugger extension handles a "Debug Session". Addressing these issues will very likely mean changing how this is performed. For more information, please see the following sections.

Beyond TL;DR The Expectations

As a user, I expect the ExtendScript Debugger to work exactly like any other debugger I interface with in VSCode. This means the following:

 

  1. A debug session lasts from when I click the "Start Debugging" button (or command) until I click the "Stop Debugging" button or the target context stops of its own accord (e.g. application closes).
  2. When the debug session is not running there is no connection between the target context and VSCode.
  3. When I adjust breakpoints while a debug session is active but not stopped, the debug session will respond accordingly.

 

The Default Reality

The reality is extremely different from the expectations. With a default configuration, the debugger has the following characteristics:

 

  1. With no breakpoints set, the debugger will appear to stop immediately after starting.
  2. With breakpoints set, the debugger might appear to stop immediately after starting. This depends on the context in which the breakpoints exist:
    1. Top level statement: Yes.
    2. Un-invoked Function declaration: No.
  3. No clear way to make the Debug Session last long enough to trigger a function from a CEP panel via CSInterface.evalScript().

 

That the debugger starts and stops immediately is extremely confusing. It really seems like there's no way to have the debugger exist in a "standby mode" that is capable of breaking on runtime script logic.

 

The Advanced Reality

By setting the debugLevel: 2 configuration option in the launch.json file, it is possible to coerce the VSCode Debugger Extension to actually handle breakpoints in runtime script logic. However, this results in the following quirks:

 

  1. The debugger will always stop at the first line of the script specified in the program configuration option when the "Start Debugging" action is triggered (button/command/etc.).
  2. The debugger appears to automatically start when a specified breakpoint is hit.
  3. Modification of breakpoints (add/remove/update) in the VSCode interface are not communicated to the background debug session automatically. This can result in the following confusing scenarios:
    1. Remove breakpoint: Ghost breakpoint triggered. "VSCode halted where no breakpoint is set!"
    2. Add breakpoint: Existing breakpoint ignored. "VSCode ignores my breakpoints!"
  4. Attempts to use Compound Launch Configurations do not work as expected. This would be a natural thing to try given that one may wish to attach to both the HTML and ExtendScript engines in a single debug session.

 

Beyond the above surprising quirks, the current implementation appears to leave a connection to a Host Application open at all times. The ExtendScript Debugger is put into a Polling mode with no clear way to break that connection.

 

Matching the Reality to Expectations

Adjusting the ExtendScript Debugger to operate more closely with expectations should be possible. Specifically, adjusting the extension to run as follows should go a long way to help:

 

  1. Create a connection to the host application and begin polling when the user explicitly Starts a debug session.
  2. Do not automatically stop the debug session unless the it ends for some unforeseeable reason (e.g. host application exits).
  3. Close the connection to the host application and stop polling when the user explicitly Ends a debug session.
  4. Watch for breakpoint changes in the adapter and update the active ExtendScript debug session live.

 

ExtendScript Debugger isn't "ESTK in VSCode"

The current functionality appears to attempt to emulate the "Play/Run" button in ESTK. The problem is that VSCode's debugging facilities are expected to run in a very different manner. This doesn't mean that you shouldn't support the ability for someone to write script and run it in a host application, just that you shouldn't rely on the debugger to do so. The ExtendScript Debugger should be adjusted to support the following features:

 

  1. A default debugging experience that works as near as possible to other debugging experiences in VSCode (see the previous section).
  2. A "Run Script in Target Host" command feature that runs the currently focused JS/JSX script in a selected target application.
  3. A "Debug Script in Target Host" command feature that effectively works the same as the default configuration does today.
  4. A "Connect Console to Target Host" command feature that provides the user with a console interface for a given engine on a target host so that they may issue direct commands to it (and possibly show a live-updated set of global data as with the ESTK Data Browser?).

 

Such an approach should do a good deal to clear things up for users and offer them desirable features that they have grown accustomed to with ESTK.

    This topic has been closed for replies.

    1 reply

    sberic
    sbericAuthor
    Legend
    April 12, 2019

    I'll add a bit more information on why I say that it should be possible to implement the debugger as suggested in the initial post.

    Both ESTK and the ExtendScript Debugger extension for VSCode send and receive information about the debug session. In fact, both of those applications are capable of setting breakpoints and instructing the target ExtendScript engine's internal debugger session on how to perform.

    To make the ExtendScript Debugger extension perform as I've described, you merely need to do this:

    1. When the user Starts Debugging:
      1. Connect to the target app.
      2. Tell the target app+engine what breakpoints are active.
      3. Set debugLevel: 2 or whatever is necessary.
      4. Begin polling.
    2. When the user adjust breakpoints in the VSCode UI (add/move/remove a breakpoint; change a condition; etc.), the extension updates the target app+engine with the active breakpoints.
    3. When the user Stops Debugging:
      1. Tell the target app+engine that no more breakpoints are active.
      2. Set debugLevel: 0.
      3. Stop polling.
      4. Disconnect from the target app.

    [The above could also work for the "Debug Script in Target Host" command I suggested in the initial post.]

    The only further complication may be the existence of the $.bp(...); and debugger; statements (and possibly the $.level property (assuming this is similar to debugLevel). As these are user-controlled, however, you would simply instruct users to not use these features when working with the ExtendScript Debugger for VSCode. Users shouldn't actually need those statements if they're able to control a session as outlined above (specifically when they have access to realtime breakpoint control).

    This isn't rocket science and it really shouldn't be that hard to build. The main difference here is that you don't think of the extension as a "Debug Handler" but as a "Debug Controller". As I understand it, the ExtendScript/BT protocol provides you with everything you need to setup and control a Debug Session in VSCode in this manner. Benefits of this approach would include a debugging experience that matches almost every other debugging experience out there and the ability to use standard VSCode features (e.g. Compound Launch Configurations).

      sberic
      sbericAuthor
      Legend
      April 25, 2019

      sberic  wrote

      The only further complication may be the existence of the $.bp(...); and debugger; statements (and possibly the $.level property (assuming this is similar to debugLevel). As these are user-controlled, however, you would simply instruct users to not use these features when working with the ExtendScript Debugger for VSCode. Users shouldn't actually need those statements if they're able to control a session as outlined above (specifically when they have access to realtime breakpoint control).

      Actually, I just verified how debugger; statements work in the Chrome DevTools:

      • DevTools is Open: Trigger a breakpoint.
      • DevTools is Closed: Do nothing.

      The point here is that debugger; statements are entirely ignored unless Chrome's debugging session is open. This holds true for the Debugger for Chrome extension for VSCode as well:

      • Debugging Session Active: Trigger a breakpoint.
      • Debugging Session Inactive: Do nothing.

      As a user, I would expect that the ExtendScript Debugger work in the same manner. I should be able to freely add debugger; statements and calls to $.bp() wherever I choose but only have them trigger when a debugging session is active.

        J
        Jon S. Winters
        Participant
        April 26, 2019

        These are some excellent recommendations. I hope Adobe modifies debugger to produce these behaviors.

          Terms & ConditionsAccessibility statement
          Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices