Which missing feature or API is blocking your UXP migration?

Is UXP missing a feature or API that is blocking your migration from CEP (or elsewhere) to UXP? Please list it here.

@zwettemaan said recently that he knew several developers who started to migrate but were blocked and went back to ExtendScript. I’m curious what those features are… please list them in this thread.


  • Panel FlyOut menus on InDesign
  • Keyboard issues (bugs) on InDesign on Windows when a panel has focus.
    • Particularly Alt+F4 not closing InDesign but the plugin logic (not the panel!)
    • Global InDesign shortcuts no longer work with focus on plugin panel


  • Sorely missing an equivalent of the resolve Extendscript function to resolve raw specifiers into objects (ironically the .toSpecifier() is available, but rather useless at the moment)

UXP DevTools

  • Debugging scripts using UDT is way too cumbersome
  • How about some nice VSCode extension for debugging UXP code :wink:
  • Please bring the UXP DevTools CLI up to date or integrate the functionality with the main software (e.g. via commandline args or a public API)

Another current deal breaker for full migration to UXP is that in general the UXP APIs appear to be slower than ExtendScript. Not an issue for user interaction, but for doing some intensive processing on a whole document I still have to resolve to a doScript into string-based ExtendScript, either directly of via a persisted engine to keep things fast. Using doScript like this is also kind of annoying due to the limitation of only allowing very basic argument types on that function.

The latter is a request in of itself I suppose… please allow objects to be passed via doScript (probably not very feasible do to technicalities - but doesn’t hurt to ask eh :wink: )

For a clearer picture, Adobe might need to pick the brains of people that are not here on this forum… It’s not so much about migration as about ‘not bothering to try any more’.

ExtendScript was an environment where a lot of effort was made to lower the treshold for would-be scripters: it allowed creative users to try their hand at scripting.

Things that ExtendScript had, and UXP is missing:

built-in OMV
ESTK: slightly weird UI, but we all learned to love it. Debugger/editor/OMV all in one, very lightweight. I know there are people who switched to Windows just so they could continue to use ESTK when the Mac dropped 32-bit support.

The whole environment was enticing to get creative, non-scripters to try and dabble and write their first script, and that created a rich eco-system. To regain that attraction, UXP needs to get much better tooling and try to remove hurdles.

1 Like

I have already mentioned a few things elsewhere and I think one or two things are already being worked on, but here is my wish list:

  • more Spectrum Web Components … and the ones that are available still have one or two bugs :wink: It’s still beta, I know, but if you can’t install them without errors, it’s difficult to create a useful UI.

  • XMP (In the documentation but not yet in InDesign)

  • As a replacement for E4X (mentioned above):


XPath document.evaluate(…)

  • TextDecoder() TextEncoder()
  • resolve(specifier) (mentioned above)

Very useful for new project

  • Canvas Pixel Manipulation
  • Drag & Drop

  • structuredClone()

  • a lot in CSS, e.g. grid, gap property for flexbox, aspect-ratio, transform, …


Better error logging, sometimes simply no errors are output there.

For me, the biggest problem preventing migration to UXP is reading and writing text files.

One of the issues is shown in the InDesign sample script.
Even with InDesign 19.4, there are only 19 sample scripts for UXP compared to 21 sample scripts for ExtendScript. That is, two are missing.
Among them, I created “PlaceMultipagePDF.idjs” by myself while studying. (PlaceMultipagePDF.idjsを作ったぞ(ExtendScriptからUXP Scripting) | CS5)
However, “FindChangeByList.idjs” cannot be created. Because line 124 of “FindChangeByList.jsx”
myLine = myFindChangeFile.readln();
This is because there is no equivalent function, that is, the ability to read a text file line by line. Of course the InDesign team should know.
Currently, to achieve this with UXP, it is necessary to read the entire text file and divide it into arrays using line feed codes, which requires extensive rewriting.

There’s another big problem with text files. Encoding cannot be specified in UXP. All are treated as UTF-8.
However, there are some functions in InDesign that cannot handle UTF-8. First is “InDesign tagged text”. In the case of the Japanese edition, the encodings that can be handled are “ASCII”, “ANSI”, “Unicode(UTF16LE)”, “Shift_JIS”, “GB18030”, “Big 5”, and “KSC5601”.
There’s no UTF-8 here, so I can’t create the text file I want to use with “InDesign Tagged Text”.

Next is “Data Marge”. Although this function is often used alone, it has many inconveniences, such as line breaks cannot be included in the field and there is no function to automatically adjust the horizontal ratio, character spacing, and font size. , and execute it using a script, including the processing after data import. However, in the case of Japanese, the encoding of the source file will be “Unicode (UTF16LE)” and “Shift_JIS”. This is because this function cannot handle UTF-8.
I’ve been requesting this from the InDesign team for quite some time, but there’s no sign of it ever happening.

There is also a problem with newline codes. In InDesign, Chr(10) is a Forced line break and Chr(13) is a Line break, so you need to use them properly, but in ExtendScript, there is a problem that both are replaced with the character of odeline break setting. UXP doesn’t allow reading line by line, so I’m not sure what the problem is.

One of the issues preventing migration is the issue with ExtendScript’s own objects.
Typical examples are $object and UnitValue object. $objects are commonly used in any application. The UnitValue object is required in countries that use units of measurement other than points. It probably doesn’t matter much for Photoshop, but it’s essential for InDesign and Illustrator.

Script UI has become essential for scripters. In InDesign Dialog, if you create a dialog with checkboxes for each paragraph style, the dialog may extend beyond the screen depending on the number of paragraph styles. We were able to replace those parts with Script UI. However, this cannot be done easily with UXP Scripting, so you must consider UXP Plugin. I would like to be able to easily handle dialogs in HTML with UXP Scripting.

Finally, there is the issue of tools.
For scripters, the most important thing is the one-liner. While writing a script, it’s common to run a small script with a few lines just to see what’s going on.
ESTK was very useful for doing that. Because you can run it without saving the file. You can also use the console in VSCode to run unsaved code, but you can only write one line, which is a bit inconvenient.
Currently UXP Scripting doesn’t seem to have a tool to do that. It is very time-consuming to save a single-use script with a name in order to run it, as you will have to delete it later.

1 Like

Adding commands to the plugin menu

In macOS, the menu allows for easily assigning keyboard shortcuts and easily incorporating them into an automated workflow. This is a very cost effective solution.

Users who go to the trouble of adding scripts and plugins to InDesign are people who are very interested in such customization. If it doesn’t exist, they will certainly have a poor opinion of UXP. And they will complain to the developers who are the providers.

I tried to provide it myself via the InDesign DOM menu addition feature, but found it impractical for a variety of reasons.

Change event of input type="text"

Change events on React are considered equivalent to input, but I’m using Preact and would like to clearly distinguish between them.

It looks to me that UXP has already become almost a maintenance mode for Adobe. Or simply seems that way due to lack of resources?

ScriptUI in ExScript was a bad part in my opinion. In UXP I can do what I want in more predictable manner. Even use React. In ScriptUI when I wanted scrolable panel I had to code scrolling logic from scratch :smiley: in UXP overflow CSS property should deal with it.

1 Like

The UXP developers tool is still pretty hopeless for scripts. An integrated object-model viewer is lacking (there are third-party solutions but there should be an integrated one). EX4 processing, better file handling, ScriptUI.

The ESTK and ScriptUI aren’t perfect, but as Kris Coppieters mentioned, they provide an integrated developer tool with a low threshold. And as @Omachi mentioned, in the ESTK it’s easy to rattle off a couple of lines and run them.

It has been difficult to learn how to make a packaged plug-in. I have never used ESTK or the VS Code’s plug-in for ExtendScript, but I have heard that it is easy to export a .jsxbin version. While it is not fully safe (to keep prying eyes from viewing), it was easy and built-in.

I am working on bundling my Photoshop UXP plugin, and features that require secure storage, such as saving log in information and modifying files, do not work correctly.

Thanks for asking, Erin.

The big one for me is the absence of Bridgetalk (or equivalent) in UXP plug-ins. I wanted to migrate my old InDesign script that post-processes exported images via Photoshop (to ensure best quality and smallest file size). Without Bridgetalk I gave up and went back to Extendscript.

Or am I missing something? I’ve spent many hours Googling UXP and Bridgetalk and I can’t find a single result that even mentions UXP and Bridgetalk.


Thank you, @Erin_Finnegan, for asking about this. I’ve got the following thoughts. For emphasis, some are repeated from other replies to this same question.

  1. Some processes to make it easier to create something quick by inexperienced users. While I’d personally rather have VS Code integration, even that would be too many steps for many to knock out something quickly. While I hope to never launch it again, basic ESTK functionality would be what you should strive for. I’ve got a co-worker who still uses ESTK because he knows how it works. He’s not using any code repository (git, etc.). He’s just producing scripts to solve problems and automate processes. ESTK was/is good for that.

  2. Part of ESTK’s appeal is access to an Object Model Viewer (OMV). I’ve been away from it so long that I don’t think much about it anymore, but it is surprising how many forum questions deal with things that a user used to be able to see in OMV in ESTK.

  3. Replace the Adobe UXP Developer Tools application with a VS Code plug-in. The workflow of editing somewhere else, then reloading in UXP, debugging, rinse and repeat is tiring at best. It certainly isn’t efficient.

  4. Native XML object support. I never knew until these replies to your question, but it appears that was an implementation E4X in ExtendScript. We heavily rely on the native parsing in ExtendScript. We’re taking advertising layout files from 13 different sources and parsing them to add frames for ads on pages. Thousands and Thousands of pages a day across hundreds of sites. We’ve looked at using DOM Parser with UXP, but to do that you need something like WebPack. That adds a whole new great big set of headaches and is certainly not something easy. XML parsing is a roadblock for us.

  5. Built-in equivalent to something like WebPack. Your documentation strongly encourages using something to obfuscate the code. Yet you offer no method. Even ESTK had an easy export to JSXBIN. JSXBIN, while not secure, was a nice first line of defense. The ExtendsScript Debugger for VSCode again provided a method of doing the same JSXBIN export.

  6. Make the Spectrum Web Components built in. We know it is possible since you had the Spectrum Widgets in early versions. We’re still using that limited set since to use the full SWC, you’re back to needing to use something like WebPack. A problem with the Widgets, however, they don’t match in appearance across all the applications. If you’re keeping/extending them, please make the appearance match. And you need to keep them to have something easy/simple for new users/script users. But then you’re forcing advanced users to change at least a small amount of the UI to switch.

  7. Please add the ability to add a menu item to a UXP-based Panel in Adobe InDesign. Adobe Photoshop supports it. Not a roadblock, but it would be nice since, as far as I know, I can’t fully remove a menu in the menu bar upon quit.

  8. Please add some ability to easily allow the users to add PERSISTENT Keyboard Shortcuts. ExtendScript didn’t allow this either. We got around it by making standalone scripts that called the menu items. I assume this same hack will work with UXP, but we’ve not tried it out yet. But why make it that ugly? It should just work! I’d even be willing to do something crazy like get an Adobe Unique ID for each menu item if it would make it easy and persistent for the users. Again, I don’t want to force the keyboard shortcut on the user, I want them to be able to pick what keys they want to use using Adobe’s built-in Edit > Keyboard Shortcuts... functionality.

  9. I think there are like two events you can monitor for a text field in the UI elements (input and paste). Not a roadblock, but it’s going to change how we go about building certain aspects of the UI. UDT’s view shows there are additional events that are known about, but why aren’t they wired up?

  10. Documentation! I’ve been harping about this since my first day. When was the last time something new was added?

  11. Drag and Drop isn’t a requirement for us-yet. Coming from ExtendScript, we don’t currently use it. But starting with UXP in Adobe Photoshop, I expected it would be an option. We would certainly integrate support for it if it was available. For us, we want to drag and drop something from a UXP Panel into a document and then trigger an event. And look how many people on the Forums are asking about making it work!

Positive Things about UXP:

  1. I am ecstatic about the demise of ScriptUI! Adobe abandoned it ~15 years ago, so it is nice to have modern UI components that can match the native appearance of the application’s UI. Yes, I know there are some who miss it. To each their own. I was expecting the transition to be more difficult. But I have slowly constructed a simple library of code for common elements and it is now very fast for me to bang out a new dialog. But it would have been way easier if there had been some better documentation. And it wasn’t clear to me for quite some time that the built-in spectrum widgets a) behaved differently than the SWC which b) weren’t even available at that time.

  2. I’m very happy to leave ECMAScript 3.2 behind and advance to version 6! So glad to have a modern language. I definitely use the newer features.

  3. One positive aspect of the Adobe UXP Developer Tools application is the ability to set it to look at the UI elements. It’s flaky, but when you get it working, it is helpful to assess the cause of the appearance of an element. That was a bigger help in the beginning, however. Rarely need it now.

jsw (For Erin: the guy with the treadmill desk)


I’m adding not a blocker but a feature request: The ability to have a dialog adjust to the size of what it contains. AKA to ‘flex’ a dialog. Perhaps I just don’t know how to do it, but it seems like it currently isn’t possible if you want to prevent it from exceeding the monitor’s bounds.
Along the same lines, some documented way of handling the User Interface Scaling so that we can scale dialog and content to match what the user has selected, but again, not make it too big for the monitor’s bounds.


I think dialog wants to fit its inner content… if you restrict inner content max size then it will help. But I miss feature to change dialog and more importantly popover size after it is shown.

Thanks @Jarda on the concept of limiting the inner content. I’ll see what I can do if we ever make a dialog from scratch again.

Yeah, in ExtendScript with ScriptUI, I had several dialogs that dynamically changed sizes once the user exposed certain features. It seems all I can do now is reserve the blank space (or let flex properties move something else into that space and have the blank space later). Admittedly, this is what Adobe does in some of its own InDesign dialogs (Settings/Preferences).


for me those are

  • a lack of alternatives to some helpful CEP methods, CSInterface.prototype.resizeContent() comes to mind;
  • no way of using something similar to app.system() even with user’s consent;
  • a lack of an alternative to ScriptUI.environment.keyboardState that was able to detect a modifier key while performing a script;
  • learning curve is a total bust, async/sync is a mess. ExtendScript was primitive but simple to use, UXP requires a PhD in Javascript and frameworks. The same things that were 1 liners before now are 20 imports and 40 lines.