That is great! There was also an issue with the decimal point in localization. In Czech, we separate with coma unlike English, with a dot. And I had to do additional steps to read and write values. I think that is not how it works in a web browser.
Also, it supported max 2 decimal places. No step support. None of this happened because of the Drover migration.
hi @samgannaway I have tested my UXP plugins with the latest Photoshop Beta builds, and unfortunately some of the bugs I had already reported in the prerelease forum have now also made their way into the official Photoshop 27.7 stable release.
All the issues I am referring to have already been reported in detail in the prerelease forum over the past weeks, with diagnostics, code snippets, version comparisons, and workaround attempts.
If helpful, I can send you the link to the prerelease thread by private message or email. The context is much clearer there, since the main regressions, code snippets, analysis, and version comparisons are collected in one place.
Thank you for your time and for looking into this.
@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 <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.
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.
The same dialog is used with different layouts and different dimensions set by code, but Photoshop reapplies the last saved size.
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.
A single manual resize by the user is enough for that size to be stored and reapplied forever.
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
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.
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.
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.
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.
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.
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.
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.
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
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.
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
sp-textfieldI 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.
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.
Even resizing panel with a few textfields and checkboxes is now super slow. Panels without it are fine.
I can confirm that the drag sensitivity issue (Clicking a draggable container frequently triggers a drag instead of a collapse/expand) is fixed in the latest PS build 27.9.0 (20260610.m.3569).
Hi Erin,
first of all, I can confirm that one of the four issues I had reported has been fixed, namely the one related to “Host-side cache of UXP dialog dimensions”. Thank you very much for addressing this.
Regarding the other reports that are still under investigation, I tagged you in a prerelease post where I added further checks, code snippets, and demonstration videos. I hope they may be useful for the team to better analyze the different cases.
I have also tagged you in a new prerelease post about another issue I am currently seeing in the Photoshop beta on Windows. I am summarizing it here, while the dedicated post includes code, videos, and additional details.
I am seeing a possible regression related to focus and window activation for native alert() and confirm() dialogs in the latest Photoshop beta on Windows.
The issue does not occur in the Photoshop release version 27.7. In that version, the native UXP alert() is correctly brought to the foreground when it is called.
In the beta, using the exact same flow, the alert() is indeed created, but it is not correctly brought to the foreground and may remain hidden or iconized.
Plugin flow
The plugin flow is the following:
A UXP panel opens a main UXP dialog.
This dialog contains a webview.
Inside the webview, the user clicks Save Preset.
The webview sends a message to the UXP host script using window.uxpHost.postMessage(…).
The host script opens a second modal dialog using dialog.uxpShowModal(…).
This second dialog is a normal UXP dialog used to enter the preset name.
When the user clicks Save, the dialog is closed with dialog.close(“save”).
The preset is saved to a JSON file using UXP local file storage.
The preset list inside the webview is refreshed.
The host script calls the native UXP alert with alert(“Preset saved successfully!”).
Expected behavior
In Photoshop release 27.7, the native UXP alert() appears correctly in the foreground, in front of Photoshop.
Actual behavior in Photoshop beta
In the beta, the alert() exists and is called, but it is not correctly brought to the foreground.
Depending on the current window and focus state, one of the following situations may occur:
the alert() remains iconized or otherwise not visible to the user;
Photoshop seems to temporarily lose focus.
So the issue does not appear to be that alert() is not being called. Rather, it seems that the native UXP alert is not correctly brought to the foreground or associated with the Photoshop window after this flow involving a webview, a UXP modal dialog, and the subsequent call to alert().
Possible additional focus issue
I have also noticed a probably related behavior: if I call a UXP alert directly from the webview, the alert appears without being iconized, but when it is closed with Cancel, there still seems to be a brief loss of focus.
During that very short interval, a window behind Photoshop can become visible, for example a browser page or another open application.
I am reporting this only as an additional possible clue, because it may indicate a more general behavior in how focus and window activation are handled when native UXP dialogs, such as alert() and confirm(), are closed in the beta.
A general tip for anyone encountering bugs with DroverUI/UXP: I’ve had good success creating a minimal repro plugin that isolates the issue and sharing it with Adobe. In my experience, this significantly speeds up the process, the team can reproduce the problem exactly and act on it much faster.
Creating a stripped-down repro plugin might sound like extra work, but with AI tools it’s actually quite quick these days. You describe the failing behavior, get a bare-bones plugin scaffolded in minutes, and trim it down to just the essentials that trigger the bug.
Thanks, @tomzag, that’s great advice.
@svumme did share a sample in the Photoshop prerelease forum (linking to it here for reference but note that access is exclusive: Adobe Prerelease )
Hi svumme,
The issue “Native UXP alert and confirm dialogs are not brought to the foreground” is fixed and will be part of the next Ps Beta build later this week. Once the new build is released, could you please validate the fix on your end? Please do let us know if you face any further problems or unexpected behavior. Thank you for your support.
Hi Jason, The text truncation issue and the placeholder text not appearing in italics have been fixed and will be part of the next Ps Beta build later this week. Once the new build is released, could you please validate the fix on your end and share feedback? Thank you.
Hi @SandeepSharma ,
Thank you very much for the update.
I really appreciate your help, and I also want to thank @Erin_Finnegan and the whole team for the attention and support you are giving to these reports. It is very encouraging to see these issues being followed and fixed, and I truly appreciate the work behind it.
I will install the next Photoshop Beta build as soon as it is available, verify the fix on my side, and let you know the result.
There are also a few other issues I have already reported, and I hope they can be resolved soon as well.
Since we are on the subject, I would also like to ask something related to UXP development: is there currently any supported way to make WASM work inside UXP?
As far as I remember, it used to be possible until about a year ago, but then it stopped working. I do not know whether this was an intentional decision to remove or restrict support, but having WASM support in UXP would be extremely useful, especially for more performance-critical plugin features.
Thank you again to you, Erin, and the whole team for your support and for the work you are doing.
