Weird app.doScript() behavior

[jduncan]

So, @Kurt Gold has been helping me sort out some bugs with my Ai Command Palette script and we've run into some odd behavior executing actions. Original Kurt, reported an action on his Windows computer wasn't running correctly when initiated via Ai Command Palette, so he shared the action with me for testing. During testing I encounterd some really odd behavior. I have detailed everything below and also included a screen recording of me trying to execute the script and action a few different ways with mixed results. Hopefully someone has an idea of what is going wrong. Thanks in advance for any help on this!

Odd behavior #1, his action ran just fine on my Mac computer when initiated via Ai Command Palette. To try and sort this out, I made a simple script (see below) to test only the `app.doScript()` method without all of the overhead that comes along with Ai Command Palette.

try {
  app.doScript("polygon_inside_circle", "Test Group");
} catch (e) {
  alert("Error\n" + e);
}

When ran from "File > Scripts > Other Script...", this script works fine, and the action works correctly.

Odd behavior #2, when I tried this simple script via the JSX Launcher plug-in (which I use daily and rarely have any issues), I get an error. So, I then tried the drag-and-drop method of running scripts by dragging the simple script file onto the artboard and it still didn't work.

Odd behavior #3, puzzled, I loaded the script into Ai Comand Palette, using it's script running capability, and it runs just fine.

So this simple script, that fires a pretty simple action isn't working consistently and I have no idea why.

A few notes... Kurt's action does have some localized (German) values within it, but it that doesn't seem to affect how it runs. I don't have permission from Kurt to share the action but will share it here if he is okay with that. For reference, it is only a few steps, and all simple menu commands.

[sttk3]

Depending on the route used to execute the script, the position of the undo state and the state of the selection after the action is executed will change.

In this case, I think it is most likely due to the fact that the action is dependent on the selection state.

The routes are as follows

• Execute from the script menu
• Open the jsx file in Illustrator
• Drop the jsx file on the document
• Execute from do javascript

[jduncan]

Thanks @sttk3! I follow what you are saying and figured that may be the case (even though I've never experienced it when testing scripts and actions)... But, the original issue was that the action works correctly on Mac but not on Windows when ran via Ai Command Palette (which just uses `app.doScript()` under the hood... So, I'm hoping someone may have an idea as to why.

[m1b]

Hi @jduncan, I don't think I can help with testing here because I'm also running MacOS. However, I was thinking about @sttk3's comments and wondering if there is anything you can do—before executing the script/action—to "normalize" the app state no matter which ways the command is started. I'm just hand-waving here, but wondering whether, say, executing via an idleTask will do that. Or maybe there's another way... Or maybe the problem is something else...

- Mark

EDIT: Sorry about the "idleTask" idea... that would only work in Indesign. I'm sleep-deprived and lost track of which forum 🥱

[sttk3]

@jduncan As I recall, there was a problem in Windows where actions that were selected (active) in the action panel could not be executed by scripts. I searched and found the same statement in addition to mine.
object "play action" not available

@m1b As for undo state, app.redraw() acts as a kind of "commit" and that makes the difference less. As for the selection state, I sometimes work around the problem by reproducing the state that should be there on the script side.

[Kurt Gold]

The download link to the action set is here:

Polygon inside Circle

Also, refer to a recent thread here:

https://community.adobe.com/t5/illustrator-discussions/how-to-convert-one-shape-into-another/m-p/140...

I think it's not specific to just this action, though.

sttk3, you are correct that it works when deselecting the action in the Actions palette. Well, at least almost.

For some reason at the end of the action, one or a couple of objects (actually the circles that were initially selected) get selected and, funnily enough, the Move dialog opens (!?) although it is even not a part of the action itself. In the Move dialog there are then the last used settings.

One has to escape the dialog and then all is well. But it's definitely strange.

[Kurt Gold]

I did some more testing and what I see is that deselecting the action (set) that is going to be executed with Josh's Command palette just *sometimes* cures the issue partially. Some other times it does not help at all and, surprisingly, some other times it does not matter what's selected in the Actions palette. It then may work correctly or may fail completely when using the Command palette. Currently, I cannot see a unique pattern and I'm afraid this is a tough one to get it right.

[jduncan]

So, I found some more oddities to add to this... This morning, when I first tried running the action, it worked perfectly in every situation I mentioned above (JSX Launcher Plug-in, File > Scripts > Other Script..., Drag-and-drop, and from Ai Command Palette. Then I removed test action and restarted Ai, then re-added the test action and restarted Ai so it would register, and now running the script from JSX Launcher, and Drag-and-drop don't work again but the Scripts Menu and Ai Command Palette do. As a last ditch effort, I tried capturing the current selection, resetting the selection, doing a redraw, and then resetting the selection, and that didn't seem to help...

This may be something that there is no answer to. Not only is the behavior inconsistent between Mac and PC, but also inconsistent even on the same machine.

Unfortunately, I think I may just have to put a WARNING on Ai Command Palette that some Actions may not work as inteneded.

[sttk3]

Another concern is whether the focus is on the Illustrator app at the exact moment the action is executed.

This is rarely a real problem, but there used to be a note that the focus must be on the Illustrator app when the action is executed.

[Kurt Gold]

Thanks for this additional impulse, sttk3.

In all my tests the focus was certainly on Illustrator. Of course, you may mean something different that I'm not aware of.

Anyway, as far as I can see the behaviour is just unpredictable. The only pattern I can see so far is that Illustrator's regular Move dialog appears pretty often when running actions through the Command palette, although it is definitely not incorporated in the actions I tested. Quite funny somehow, but it's a pity because this specific feature to run actions with Josh's Command palette is (or could be) super useful.

[sttk3]

This probably has multiple causes involved, but at least it seems able to explain the JSX Launcher error.

Recall the two messages it displayed.

• The selection is not valid for this filter
• The object "Simplify" is not currently available

This seems to indicate that the selection is empty.

Now let’s look at @Kurt Gold ’s action.

Since it is "Simplify" making the error, it seems likely that the selection was lost after the four preceding steps.

• Copy
• Paste in Front
• Set color
• Transform Each

I am familiar with this field, so at this point I already have an idea that "Paste in Front" is suspect. Then, I experiment with only starting from "Set color" without selection. As expected, I get the same two messages as in the JSX Launcher.

The results of the experiment show the following.

• Empty selections are likely the cause
• "Set color" and "Transform Each" do not raise an error even if the selection is empty
• It is likely that the selection was lost between after "Paste in Front" and before "Simplify"

Therefore, possible countermeasures are to add a pause after "Paste in Front" or to explicitly reselect the duplicated path in the action. Dash Nipper has such a process, if I remember correctly.
[JS] [Action] Split or break a dashed line into separate (real) lines by script

[Kurt Gold]

Very good points, sttk3.

I'm still testing and unfortunately there are various really unpredictable behaviours when running the actions through the Command Palette. Even most simple actions that involve just one or two steps show weird issues (or not, or sometimes, or always).

I will call in if I see some reproducible pattern.

[Kurt Gold]

For example, an action that just runs the regular Deselect command triggers the Move dialog (???) instead of deselecting the currently selected object. Does only happen when using Josh's Command Palette.

What is more weird: It sometimes works, but most of the time just not. Usually, I'm not a galoot. In this case I'm perplexed, though.

[jduncan]

Yeah, this is what is unfortunate... Since Ai Command Palette is really just a launcher/executor (in the case of actions), I have no control over how users build their actions. I literally had no idea this was even an issue. I run my own action everyday via Ai Command Palette, and have never encountered and issue since I added the feature of executing actions.

[sttk3 · Accepted solution]

@Kurt Gold It is strange that the move dialog appears. There are several possible causes for this

• The Enter key after typing a command is the cause of the move dialog
• Another workflow created by an app or plugin (let’s define it as a caller app) that calls the Ai Command Palette is being executed
• When the caller app executes a script, it should exit without waiting for the result, but in fact it is waiting

@jduncan Ideally, this case should succeed without any special tricks; it is a case that Illustrator should handle well. All we can do is to report it to UserVoice, or to make a small tweak like the one I mentioned before.

[Kurt Gold]

During some further testing yesterday I also suspected that there must be some conflict with the Enter key here. I think you basically hit the bullseye with your assumption that there actually is a conflict with the Enter key when the Command palette is called by script launcher plugins. I tested "Scripts Panel", "LAScripts" and "Scripshon Trees" and they all cause the dorky behaviour when launching Josh's palette and starting actions with the Enter key.

There are some other inconsistencies that are not bound to the script launchers, as far as I can see. This requires some more and different testing. And it may or may not depend on the localised versions (only).

Thanks for chiming in, sttk3.

[jduncan]

This may explain why I have never experienced these issues (with Actions) in my daily use. I fire Ai Command Palette via a keyboard shortcut (not a launcher) so I am technically running it via 'File > Scripts > AiCommandPalette.jsx'.

[sttk3]

@Kurt Gold When a script launcher waits for a result when executing a script, in other words when it executes a script with a modal operation, the keys typed during that time are added to a queue of some kind.

Then, when the modal is released, the process in the queue is executed. This is not the intended behavior. Thus, the script launcher should relieve itself of its duties the moment it sends a request to execute a script, unless it is absolutely necessary.

I agree that other factors are also involved, so please let us know if you find any laws or characteristic behaviors.

@jduncan It makes sense. In fact, consistent use of one type of environment may have provided stability.

[jduncan]

Ai Command Palette does execute the action inside of a try block so I may test removing that try block to see if it has any effect. Seems like it shouldn't but at this point I have no other ideas.

As for a consistent environment, yes you are correct. Although, I have tested all functionality in Ai Command Palette on both Mac and Windows, and by also via multiple launchers and the regular script menu. I think this bug has come to light due to a weird coincidence of system, usage, and certain action steps, and I'm just not sure there is a fix. I do appreciate both you (@sttk3) and @Kurt Gold for helping to try and solve this.

[sttk3]

Removing the try syntax is unlikely to have any effect; it may be possible to address the problem in ExtendScript by, for example, passing the process to BridgeTalk and ignoring subsequent moves.

However, even if you do that, the same problem can occur if the upstream script launcher has not taken a similar action. So it is up to you to actually incorporate such processing.

If this were me, I likely would not do it, and would try to solve the problem by providing a script launcher that is closer to the OS side.

[jduncan]

Sorry, I got tied up on other things and never got back to this. After some testing, I think there is a genuine bug in the `doScript()` method when running actions that interact with the document selection. Let me explain.

Take a simple 1-step action that runs the `Select > Deselect` command like below and activate it with a simple 1-line script like below.

app.doScript("Deselect", "doScript Testing");

After running the script, you'll notice that your original selection of items stays selected like in the screen recording below. Note, that the action works correctly when run from the Actions panel.

It seems as though, Ai, or the ExtendScript engine, does something after the `doScript()` method runs. If you add a stop at the end of the simple 1-step action, you can see that the selected page items are actually deselected, but then are reselected as soon as the action ends.

I have tested this using the built-in `File > Scripts` menu, the drag-and-drop method, and using a script runner (e.g. JSX Launcher).

Things I've tried to fix this.

• doing `app.redraw()` before and after the `doScript()` call
• saving the current selection, redrawing the screen, resetting the selection, then calling `doScript()`
• adding a stop to the action
• running this on a fresh start-up of Ai
• running via different launch methods
• a bunch of other stuff I have forgotten (but didn't work)

There may be other action steps that also don't play nice with the `doScript()` method, but I have only tested the selection commands at this time.

I plan to file a bug report for this later this week.

[sttk3]

Your prediction is probably correct.

Originally, there existed a phenomenon that caused the selection to be lost when executing an action in Illustrator with doScript. A fix for that phenomenon was initiated in the Illustrator 2021(25) era and completed in 2022(26).

When scaleAction Javascript is applied on the selected objects, the objects are deselected

However, it was probably a temporary solution that reselecting the selection after executing the action.

When I tried to run the Deselect All action via doScript in Illustrator 2020(24), which was before the fix, it did not reselect and gave the expected result.