Adobe UXP bug report — native form-control transparency blocked (Photoshop)
Recent PS update blocks `<textarea>`/`<input>` transparency + breaks button/input styling (UXP regression)
I've been developing a plugin for 1.5 years, had it working beautifully with styled themed
backgrounds, and was waiting on Marketplace seller verification. A recent Photoshop update has
blocked `background: transparent` on native form controls in UXP, which has taken an
otherwise finished, ready-to-ship plugin out of commission.
Environment
- Photoshop (release): `<FILL IN — Help ▸ About Photoshop>`
- Photoshop (Beta): `<FILL IN>` — **reproduces identically in Beta**, so this is unfixed across the current pipeline (no staged fix)
- UXP runtime: `<FILL IN — require('uxp').versions>`
- macOS: `<FILL IN>`
- manifestVersion: 5
What broke
1. `<textarea>` / `<input>` no longer honour any transparency. `background: transparent`
(and even low alpha such as `rgba(255,255,136,0.01)`) renders as a solid dark block
instead of showing the layer/paper behind. My notepad relied on a transparent textarea over
a themed paper background with ruled lines behind — it is now a dead dark rectangle.
2. `<button>` native chrome is back (rounded/tall), overriding CSS.
3. `<input>` fields are rendered far too tall (UA height injected).
What I have already tried — none restore transparency
- `-webkit-appearance: none !important` / `appearance: none !important`
- `background: transparent !important`, and low-alpha backgrounds
- `transform: translateZ(0)` + `will-change: transform` (force a compositing layer)
- `<sp-textarea>` with Spectrum tokens (`--spectrum-textarea-background-color: transparent`)
- ruled lines as a CSS `repeating-linear-gradient` background on the textarea
→ renders only in the side padding gutters, not across the field
- ruled lines as a tiled PNG `background-image` on the textarea → not rendered
- ruled-line divs in an overlay layer above the textarea → hidden by the native control
- ruled-line divs on a layer behind the textarea → hidden (textarea paints opaque over them)
- `contenteditable` div instead of a textarea → transparency works BUT the element is not
typeable in UXP, so it is unusable as an editor
- bumping `host.minVersion` to the current PS version → no change (confirms this is host-wide,
not gated on the plugin's declared version)
Only thing that works: a fully opaque `background-color` on the control. Any degree of
see-through fails.
Impact
Any plugin that layered UI behind a transparent input/textarea (lined-paper editors, themed
note fields, custom-styled inputs) is broken. Opaque-only is the sole workaround, which loses
the design.
I understand this appears to be intended, not a bug. Per the UXP UI docs, a text-editing
widget always renders its editor above everything else in the panel, and the native text engine
forces a solid theme-coloured brush behind the field (to avoid text aliasing/ghosting). That
single rule explains every failure above — nothing can sit behind or over a text widget, and its
background can't be transparent. So I'm not asking for a "fix" so much as a supported path.
Request
1. Please confirm this is the intended behaviour of the Spectrum-native form-control change
(moving `<textarea>`/`<input>` to native control delegates), and that it shipped in the host
C++ container (hence bypassing manifest/host-version gating — declaring an older
`host.minVersion` has no effect, which I confirmed).
2. Is there any supported opt-out — a flag, an attribute, or a legacy rendering mode — to get
a text-editable field with a transparent (or CSS-controlled) background, so UI can be layered
behind it?
3. If not, could Adobe consider a lined/graph-paper or transparent-background input primitive,
or documented guidance for custom text editors? Right now the only text-editable element that
accepts transparency (`contenteditable`) cannot receive typing in UXP, so there is no viable
route to a custom-painted editor.
Thanks — happy to provide a minimal repro plugin if useful (I have a test panel that demonstrates
each case side by side).
