Concerns about migration of CEP extension to UXP

I’ve been reading through the new information about UXP and the announcement that it will be replacing CEP.

If this happens it will likely mean the end of our current CEP extension, since the support provided in UXP does not cover our use case. To be specific we have problems with the following areas:

  1. Most critical UXP is “not a browser” and as such will only support a subset of HTML. Our extension relies on being able to run another web application within the browser control supplied by CEP, in an iframe window. While there is currently no list of supported HTML, it seems likely that iframe will not be a supported HTML element.

This will break our CEP extension.

  1. No support for persistent panels. Currently there is only support for Modal Dialogs, which are expect to be invoked and then closed. Our CEP extension relies upon a persistent control, which the user logs into once.

  2. In ability to access the user file system, in particular the Download directory. This will break a few features in our application which rely on being able to read information from this directory.

At least that just got “resolved” with today’s update :wink: – see

So basically, you’re asking for support for “peristent file system access”? In this case, take a look at Persist file references

May I ask what you’d need an iframe for? If I may be honest, I can’t think of a good reason to use it (too big are privacy concerns associated with it). Could you possibly elaborate on use-cases here?

By the way: welcome to the forum :wave::slightly_smiling_face:

1 Like

No, maybe I’m misunderstanding the information in the API reference, but it appears that there is no way to get access to files that aren’t in the plug-in directory, or under it. Downloads is a directory that we would want access to that would not be under the plug-in directory or sub directories.

Our use case for the iframe is to allow syncronization between our extension, and an existing web application. Essentially the architecture is as follows:

  1. Thin UI layer with a few controls at the top of the screen in a tool bar. This layer handles all of the logic that is specific to Adobe, and our feature set for extending Illustrator, InDesign, and Photoshop. We currently support things like allowing people to easily open Adobe files from the web application, saving them back to the web application, automatically creating thumbnails, and pdfs, and so on.

  2. There is a messaging layer that passes information between our extension, and the web application.

  3. The web application, which is put into the iframe. This web application is usually run by itself in a browser, and has been designed accordingly. With the messaging layer from #2 we can communicate between the web application, and the Adobe extension to handling the various features mentioned. Further our users can use all the features of the web application while it is tightly integrated into the Adobe app.

We control all three parts of this system, so the privacy and security concerns are not a problem. Further most modern browsers have locked down the iframe implementation such that those issues are no longer a problem.

Now it’s possible for our users to use the web application and the Adobe applications separately, but the extension makes this much easier, while also adding some features that are not possible without the tight integration.

1 Like

@pklaschka, can you share what are the security concerns which lead to cutting browsers functionality? I’m asking because all these concerns somehow works in browsers and all these limitations just breaks standard js libraries. Right now it’s crazy not easy to write plugins for XD because of such limitations. XD pretends to be browser but it’s not. We spend most the time not writing the features and provide string UX but looking for workarounds for new limitations we discovered. I’m not sure if you worked with Photoshop plugins but it provides full chromium with nodejs as backend with full access to the file system. Yes, it might be not secured but I haven’t heard about any complains about that.

1 Like


UXP is very much a maturing product. The version in XD < 20 was UXP 2, and XD 21 just now released with UXP 3.1. UXP will continue to mature and add more and more functionality over time, and by the time it’s released in Ps, it should have even more functionality. One shouldn’t assume that the extensibility present in XD is the same experience one will have in a point product.

If you’re comfortable, I’d love it if you could reach out to @pvij (she’s out this week, though). She’s conducting interviews to see how CEP is being used today, and cataloguing those requirements so that we can ensure that UXP meets the needs of the developers. Again note that the version in XD is very much “early days”. XD was just the first to take UXP on because it needed an extensibility solution (XD has never had CEP).

Happy to continue the conversation in DMs if you’d prefer. Also, if you’re OK with an NDA, I can invite you to some presentations that we gave at Creative Developer Summit that describes the plans for the future.


CC @ashryan, @afuchs, @Erin_Finnegan: ^^^

1 Like

Can you share the link?

Kerri I’d be happy to talk to somebody about this. I understand this is early in the product development, I know it’s easier to get changes made before the concrete hardens so to speak.

@gdreyv I thought this was mentioned in the UXP FAQ, but I’m not seeing a direct quote that CEP will be removed.

1 Like

The thing is that there are – the way I see it – basically three options:

  1. Make it a browser-like thing (basically using Chromium again, like in CEP). This would make it easy to have these APIs, but would also (most likely) destroy all the performance and light-weightness XD has right now. This, therefore, isn’t an option, in my opinion
  2. Implement a custom system
    2.1. With support for all “web-things” like iframe => concerns about privacy and security (without some sort of way to block it, you could basically add anything into a plugin that’s installable not as a download from a somewhat shady-looking website, but from a plugin manager where a user believes he/she can trust plugins). Furthermore, this requires many measures to get taken to prevent XSS and all that “good stuff” browsers have to protect users against (which would probably lead us back to version 1: Chromium).
    2.2 Have limited support for such “difficult” areas. While this, of course, isn’t perfect, and there are always those cases where option 1 would be a better choice, that’s a thing that comes with a platform and is an opinionated decision that can go either way (personally, I prefer this option).

To me, (no offense to anyone who wants to do that, that’s just my opinion :wink:), simply integrating a web application feels cheap (not necessarily in a bad way, but as in “trying to avoid costs for porting”). It is a quick (and more or less low-cost) way to port an application into an app as a plugin. While that, by itself, is no problem, this requires thinking about the host as a kind of “modified browser”, which, again, requires a very heavy implementation underneath. I, personally, see XD as more of a platform (like a mobile device, for which I might write a native app). It is a “normal thing” to reimplement a view layer of an application to a new platform and thus, it – to me – feels natural to do so for an XD plugin.

I totally get the other side of it. It’s just that in my personal opinion, choosing a way that sacrafices its key principles (performance and feeling light-weight in XD’s case) just to stop us as developers from having to implement it for a platform instead of a modified web browser wouldn’t be right. This is an opinionated issue, but UXP is a new platform and must go it’s own way in that regard. Personally, I would love for it to stay lightweight, I get why others might think otherwise, but I’ve yet to hear one case where it isn’t possible to create something without things like an iframe (it may be more work to do so, but it’s most likely far from impossible).

I think Adobe folks have said publicly (can’t find it now) that webviews are planned for UXP. Wouldn’t that solve 99.9% of the cases where you’d need an iframe?

1 Like

Agreed. I hope that there either won’t be any powerful brdiging possibilites (as then, I’d again have concerns about security, and therefore trust into plugins), but other than that, this should (in my opinion) cover the edge cases mentioned in my comment above. I also don’t have anything “against” an iframe, but then, there should, in my opinion, be a notice about the plugin using that, which users have to agree to, before the plugin gets run (and still, if there’s bridging, XSS and so on will pose issues again).

@pklaschka I think you might be right about it being cheap in some cases. However the web app that I’m putting into the iframe is an enterprise level application, and it’s too large and complex to be ported over to another platform. Just to give some perspective, we’re in the 100K lines of code range, with a very large development organization.

I also disagree that this adds any addition security issues that weren’t already present. The locking down of the file system seems to be more important in this regard that any concerns about iframes, particularly since it’s a solved problem. CEP gets around this problem by leveraging all the existing security already implemented.

I appreciate the desire to be lightweight, and not bogged down by heavy weight implementations, but sometimes you need to make that tradeoff. The lightest most efficient implementation is going to be to do nothing with no code, but it’s not useful. :slight_smile:

Maybe there’s something here I don’t understand. Can you explain to me how I could continue to do this without using an iframe? I don’t see an option to create an UXP port of the web app, and it’s not clear how WebViews would resolve this problem. Can somebody provide a link to the discussion of WebViews for UXP?

I’m no CEP nor UXP expert, and can’t speak for Adobe’s plans, but ISTM that if you have a full-fledged webview to run your web app, and some way to communicate between your UXP code and your webview (which has to exist or webviews would have no point), then Bob’s your uncle.

(Except of course if you were relying on Nodejs functionality that has no equivalent in the UXP for your particular point application, e.g., Photoshop.)

Sounds reasonable, but the devil is in the details. Can you provide me with some information about the WebView that will be supported/added to UXP?

That would be up to Adobe, sorry.

@JohnMore: we don’t have any public info on any potential WebView at this time. For now, the right path is to get in touch with @pvij when she is back next week. @Erin_Finnegan, is there still a signup for that, or are we scheduling meetings with Prerna case-by-case now?

You may still sign up here to talk UXP requirements with @pvij. (I’ll also remind her to check for responses when she’s back next week.)

1 Like

I’ve signed up, but haven’t heard anything from @pvij Is there some way to follow up on this?

She just got back, and I’ve just reminded her to follow up.

Hello! Sorry about the delay in my reply. We can most certainly setup a time to talk about your usecase. I’ll send an invite soon.

1 Like