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 <webview> 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 <webview> 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 <webview>. 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:
<PluginID>_<dialog.id> = [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\<PluginName>\
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 <webview> 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.