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?
Hot Module Replacement/Hot Reloading. With tooling for frameworks like Vue CLI or React equivalents which use Webpack, every time you save changes to any related file, your bundle will be reloaded within a specified localhost port for ease of previewing changes. With the current workflow I don’t see a way to do this via UXP despite being able to easily do so in CEP by embedding my panel in an iframe pointing to the same localhost that my tooling compiles to – this is a critical point in ease of development for me because now I presumably have to take additional steps to manually reload any plugin or panel to see changes while developing while losing current states/routes in doing so, which HMR solves.
So, internally, we have components that use live hot reloading without the need for IFRAMEs. This depends in part on the webpack config (we should open source those when they get stable), and generally works really well, although there are sometimes issues with ATS on macOS (blocking localhost turns out to be a problem for HMR…)
XD plugins are a slightly different beast since there’s more there than just HTML (you have to export panel handlers, etc.) But HMR is something I’d love to see supported by XD plugins for the very reasons you state (devex is much easier).
Hey everyone, I found this thread very interesting since we also build CEP extensions that rely heavily on iframes to connect the CC user to our backend enterprise application. I understand the security issues, but I also agree that having the user click-to-agree on things like filesystem access, etc… should be enough. For us at least we supply the extension to our clients, to help them better prepare PSD or AEP files for our system, so there are no security issues for them whatsoever.
Has there been any progress or development on the topics listed here above since July 2019?
We can also share our concerns on UXP limitation in these specific areas with a representative of Adobe if they feel they would like to know more…
Hi, we also have the concern about the iframe support in UXP. We also have enterprise application that uses CEP to show a webview (hosted by company) and interact with host application. The web view is put inside iframe.
Our CEP extension/application intend to provide consistency UX behavior across different platforms (including when viewing from native browser), and having a full chromium engine is the only way to achieve the consistent UX behavior.
Now it turns out that UXP is not a browser, we’re very concerned about this approach, it seems UXP has been limited to only lightweight UI/scripting development, and it kills the need of integration with external/3rdParty webviews.
Not having full web support is definitely a step backwards
Plugin platforms for popular applications (e.g. Sketch, Figma) now have full Web support, which allows a lot of code to be shared between plugins developed for these platforms and CEP
For design tool plug-in developers UXP makes developing plug-ins much more expensive, not at all like an upgrade to CEP, and frustrating for developers
I understand how this might seem frustrating to you. However, it takes a lot of resources to host a web browser-like instance for every single extension that gets loaded.
So while UXP will never be CEP, and thus, will never be a full browser, we are working on improving the developer experience surrounding that in several areas:
We are improving UXP to, over time, support more and more features.
We are currently adding web view components to UXP, which allow embedding a browser-like instance in such cases where this is necessary. The first version of web views was already rolled out in Photoshop a few days ago, allowing you to host such web views in modal dialogs. We are also actively looking into supporting this directly inside your panels. For more details, see https://developer.adobe.com/photoshop/uxp/2022/guides/uxp_guide/uxp-misc/manifest-v5/#webviews
On another note, I would (from my personal experience as a plugin developer) recommend thinking about UXP less as a browser and more like something along the lines of react native. Thinking about it like this helped me a lot: the patterns of how you can, for example, share code between code bases is very similar between React Native and web applications and UXP and web applications. And while things like web views will help integrate more complex user interfaces, they shouldn’t be your default for every plugin.
I understand that this probably isn’t the answer you were looking for. Still, if your code base is complex enough that it is too complicated to adapt to UXP, I would recommend looking at the web views since they might be able to help with these use cases.
Also, if you have any use cases where you currently cannot find a way to solve them, please let us know!
Thanks,
Pablo
PS: please note that we are still working on providing extensive documentation around web views (Especially around the communication between the web view and the surrounding plugin). There is also a web view sample included in version 1.6 of the UXP developer tool, which is currently being rolled out.