And now a message from one of our infrastructure teams: Hi Everyone, We are pleased to share that the Photoshop’s backend infrastructure for UXP plugins has been updated and is now available in the Photoshop Beta build: 27.8 20260510.m.3537 This update ensures a more consistent look and feel for Photoshop UXP plugins across Creative Cloud applications and lays the foundation for future UI enhancements and shared capabilities. What this means for UXP plugin developers? For the UXP plugins not using Spectrum components, this update would bring your plugin’s UI to a lot closer to a Spectrum based UXP plugin. For the UXP plugins using Spectrum components, this change is largely not expected to impact UI look and feel, except for changes in text font size and placement of text with in the text area. Before this change Ps was ignoring the font size of the text field (sp-textfield) passed down from the plugin and always used a fixed size to render the text. With this change, Ps will handle the font size passed from plugins and use that. If the font size inside text fields look different in latest Ps Beta, please try updating the font size in your UXP plugin code. Our bundled UXP plugins provided a good testbed for the change, but we acknowledge that it is not exhaustive. Please test your UXP plugins in the latest Photoshop Beta and share feedback here if you notice any visual changes or functional issues. Your input is important and will help us ensure a smooth transition as we progress toward a full release. Please share your feedback, questions or any issues you encounter by replying to this thread. Thanks, Photoshop Team

@Erin_Finnegan any thoughts on why it is NOT actually fixed as you said? Did you test and confirm it is fixed? Maybe it is just me?

any thoughts on why it is NOT actually fixed as you said? Did you test and confirm it is fixed? Maybe it is just me? Hi @JasonM, In this instance, I’m just the messenger. I passed along what the Photoshop team told me in good faith, I haven’t done testing, (and I don’t have your particular test case ready to go). The Photoshop team told me they’re meeting with you tomorrow to help understand your use case, so I hope it goes well!

Hi @samgannaway , @Erin_Finnegan I had some time to consolidate the issues I previously reported across several prerelease posts, so I am summarizing them here in a single place. I am also sharing this publicly because it may be useful for other UXP developers to understand some of the current limitations and regressions affecting dialogs and workflows in recent Photoshop builds. Some of these issues, originally observed in the beta builds, have now also reached the official Photoshop 27.7 stable release and are still present in the 27.8 beta. All the issues below are host-side regressions related to UXP dialogs and behavior. They were not present in Photoshop 27.6 stable. I have already reported them in the prerelease forum over the past weeks, including diagnostics, version comparisons, snippets, and workaround attempts. If useful, I can also provide a complete reproducible snippet and videos showing the behavior. Thank you for the update on the new backend infrastructure for UXP plugins. I suspect that this rework may be directly connected to a series of host-side regressions that I have been reporting since March 7. I know that Cory has already forwarded everything to the team. These issues were not present in the stable 27.6 version. They appeared in the beta builds, some of them reached the official 27.7 release, and they still persist in the 27.8 beta. I mainly work with UXP dialogs that contain . In my latest plugin, some dialogs change layout dynamically. For example, the scopes can switch from a single view to a 2×2 view, each with different dimensions. I also maintain dozens of webview-based features in other plugins already available on the market. The regressions described here are host-side and outside the control of the plugin code. For each of them, I have had to introduce fragile workarounds, which do not always work and cannot be considered definitive solutions. Below is a summary of the main issues, already present in the prerelease reports. 1. Host-side cache of UXP dialog dimensions First report: March 7 Photoshop ignores dialog.style.width, dialog.style.height, and even the size option passed to dialog.show({...}). After show(), Photoshop reapplies its own internally saved size. Part of this saved state can be observed here: %APPDATA%\Adobe\Adobe Photoshop (Beta)\Adobe Photoshop (Beta) Settings\DVADialogPrefs\DVADialogPrefs.xml Entry: _ = [x, y, width, height] The problem is that this cache takes precedence in all practical scenarios. Problematic cases 1. Multiple views The same dialog is used with different layouts and different dimensions set by code, but Photoshop reapplies the last saved size. 2. Plugin update If I change the size of a dialog in a new version, the user who updates the plugin continues to see the old size saved in the cache. 3. Manual resizing by the user A single manual resize by the user is enough for that size to be stored and reapplied forever. Real example from my plugin I have an analyzer panel with four layouts: Layout: Single Size requested by the plugin: 415×345 Layout: Dual H Size requested by the plugin: 634×372 Layout: Dual V Size requested by the plugin: 322×699 Layout: Wall 2×2 Size requested by the plugin: 634×698 Breaking scenario The user opens the panel in Wall layout, size 634×698. Photoshop saves this size in the cache. The user closes the dialog. On the next Photoshop launch, or after reloading the plugin, the plugin explicitly requests the Single layout: dialog.style.width = "415px"; dialog.style.height = "345px"; dialog.show({ size: { width: 415, height: 345 } }); Photoshop ignores the requested size and reopens the dialog at 634×698, which is the cached size of the Wall layout. The visible result for the user is this: the internal webview is correctly sized at 415×345, because the HTML content responds to the plugin code, but the native window remains huge, at 634×698. As a result, a large empty or black, non-clickable area remains around the content. The behavior survives: window.location.reload() closing and reopening the panel, and even restarting Photoshop. Problem during plugin updates This issue becomes even more serious when an update is distributed. If, in a future version, I simply decide to change the size of an existing dialog, for example from 450×345 to 480×435 to add a new UI option, Photoshop will continue to read the old size saved in the cache. The user installing the update may therefore end up with the new UI clipped, off-screen, or inside a window with inconsistent dimensions. From the plugin code, I cannot invalidate this cache. The only way to clean up the situation is to ask the user to manually delete the relevant entry from DVADialogPrefs.xml, which is obviously not a realistic solution for end users. Behavior of dialog.resizeTo() I tested dialog.resizeTo() at several moments: Immediately after show() setTimeout(0) requestAnimationFrame webview loadstop webview DOMContentLoaded In all these cases, it is ignored. The same call, however, is respected if executed after a custom message sent by the webview when it is fully ready. This suggests that there is a post-show() time window during which Photoshop reapplies its saved state, overriding the dimensions requested by the plugin. Current workaround I had to make the webview send a custom message to the host once it has loaded. Only at that point do I call resizeTo(), outside the restore time window. The result is that the user briefly sees a large, empty, or broken window, which then snaps to the correct size. It is really unpleasant to see an 800-pixel window resize itself after a noticeable delay, made worse by a second bug that I mention below. CRITICAL Cold start of the Chromium renderer process When the last active webview of the plugin is closed, the Chromium renderer is terminated. On the next opening, Photoshop pays the full cold start cost. In plugins with complex graphic views, I measured times four or five times slower, with a long moment during which the dialog window is displayed completely black. Warm reopenings, instead, remain under 50 ms. Direct verification In UXP DevTools, in the Memory section, the renderer PID changes at every transition: all webviews closed → first reopening This happens in 27.8 beta and unfortunately also in the new 27.7 release. In 27.6, instead, the PID remained stable. Current workaround I had to introduce an invisible sentinel webview: 1×1 off-screen opacity: 0 pointer-events: none empty HTML body This webview remains anchored to the panel and is kept alive for the entire session. The RAM cost is minimal. It is a working workaround, but it is not official. There is no API allowing a plugin to declare itself as part of a warm pool, preventing the renderer from being destroyed when the last visible webview is closed. CRITICAL Plugin storage persists after uninstall On Photoshop 27.8 for Windows, when uninstalling a plugin from Creative Cloud, the folders in: %APPDATA%\Adobe\UXP\PluginsStorage\PHSPBETA\27\External\ \ are not removed. In particular, the following remain: LocalStorage/ PluginData/ SecureStorage/ A later reinstall therefore finds all the previous state again. On Photoshop 27.7, these folders are removed correctly. The issue becomes even more serious when combined with the DVADialogPrefs.xml cache, which lives in a different path and also survives uninstall. A user who uninstalls the plugin to “clean things up” and then reinstalls it therefore finds the plugin and dialogs in exactly the same state as before. This makes it impossible to offer customers a reliable way out of: corrupted state license issues incorrect configurations inconsistent UI caches Workaround There is no plugin-side workaround. The only option is to give users manual instructions to delete specific folders and preference files, which is not sustainable for ordinary support. HIGH The Ctrl key no longer reaches the webview Regression introduced in 27.4. Until Photoshop 27.3.1, a keydown listener on the Ctrl key inside a worked correctly. From Photoshop 27.4 onward, Ctrl no longer generates any keydown event inside the webview. Alt works normally. Ctrl also works at the UXP panel level, outside the webview. It therefore seems that Photoshop intercepts Ctrl before the event reaches the webview. This may look like a minor issue, but it has a real cost: tutorials, videos, and documentation for two plugins are based on the use of Ctrl. Changing the key means: redoing the educational material breaking an already established user habit creating confusion increasing support requests Note about the change to sp-textfield I saw your note about the change in sp-textfield behavior and font-size handling. Thank you for the notice, I will check this specifically. However, the issues described above are not simple styling differences. They are host-side regressions related to: dialog state size caching webview lifecycle storage persistence keyboard event handling opening performance The workarounds I described are only fragile mitigations, not real solutions. Since this backend update is described as the new foundation for UXP, can you confirm whether these regressions are known and whether they are already under investigation? In particular, I would like to understand whether they are expected to be fixed as part of this work on the new infrastructure. Since some of these regressions have already reached the stable 27.7 release, I am currently stuck. My beta testing is also blocked, and all the work that another person and I have done together over the past two years feels like it is being lost day after day. Thank you for your time and for looking into this.

@Erin_Finnegan @samgannaway When using sp-textfield with a number, it now shows integer values with .00. The display should ideally not change from before here. Is there a way to control rounding / number of decimals? Testing with 27.8.0 20260528.m.3556 b3d3456

I spoke with the dev team late last week and one of my main concerns was that the number fields were rounding to no decimals by default. They said they had a fix coming. I am hoping that this current behaviour is simply a patch the prevent the rounding until they come up with a real solution. I HOPE. You can manually set the decimal places using something like step=“0.1” and it appears they are simply setting the steps to 0.01 by default now instead of 1. That is NOT a great solution as it limits the decimals to 2 and always displays the extra 0’s which looks BAD. We want the original number handling back. I HOPE they are working on that.

[image] Jarda: I have virtual scrolling with 269 text fields and when I switch to Drover performance are a bit worse and rendering is more lagging. Similar observation here but worse? Performance regressions in Photoshop Beta (27.9.0) - #3 by jsyi1995

Here’s the latest from Sandeep from the Photoshop team. (Jason M, please note I did not verify any of this myself.) Reporter Issue Status Jason M Text truncation on setting XL size in text field Fixed. Pending release. Jason M Rounding issues in sp-textfields with type=“number” Fixed. Please test in Photoshop Beta 27.9 20260607.m.3566 Jason M Placeholder Text is Not displayed in Italic Style Under investigation Jarda Scrollbar in textarea on Windows Fixed. Please test in Photoshop Beta 27.9 20260607.m.3566 Jarda Slight perf degradation in text scroll Under investigation jsyi1995 Performance regressions in Photoshop Beta Reaching out to get more information. carlo diamanti UXP dialog with webview opens much slower in the latest Photoshop beta Fixed. Could you please test on latest beta and share results? AnthonyK Grey outline around solid borders Under investigation svumme Host-side cache of UXP dialog dimensions Fixed. Please test in Photoshop Beta 27.9 20260607.m.3566 svumme Cold start of the Chromium renderer process Not caused by DroverUXP changes. Under investigation. svumme Plugin storage persists after uninstall Not caused by DroverUXP changes. Under investigation. svumme The Ctrl key no longer reaches the webview Not caused by DroverUXP changes. Under investigation. Thomas Zagler Clicking a draggable container frequently triggers a drag instead of a collapse/expand Fixed. Pending release. Thomas Zagler Plugin panel scroll broken when document is open Under investigation

The number field rounding issue does seem to be fixed. It now rounds to two decimals and does not show trailing zeros…which matches the pre-drover handing. Thank you. Looking forward to the formatting and performance issues getting fixed.

I can see and use scrollbar now which is great but it does not match. I see this for div with overflow:auto [image] And this for textarea [image]

And for some reasons my SVG icons are now not crystal sharp. They are looking like they do not use whole pixel numbers anymore. [image] [image]

UXP UI backend update in Photoshop Beta

Photoshop

Jarda June 7, 2026, 8:21pm 29

Similar observation here but worse? Performance regressions in Photoshop Beta (27.9.0) - #3 by jsyi1995

Topic		Replies	Views
UXP UI Request Compilation UXP Plugin API uxp	15	549	September 2, 2026
PS 23.3 broke all my plugins UXP Plugin API bug	58	2584	April 11, 2023
HTML UI rendering performance of the UXP plug-in on Windows and Mac UXP Plugin API ui , uxp	14	721	February 25, 2026
Issue with spacebar or enter key triggering buttons in UXP plugins UXP Plugin API	31	2385	March 18, 2021
Recent PS update blocks <textarea>/<input> transparency + breaks button/input styling (UXP regression) UXP ui , bug , css	3	80	August 10, 2026

UXP UI backend update in Photoshop Beta

Related topics