Skip to main content
rob art | illustration
Known Participant
August 9, 2026

Adobe UXP bug report — native form-control transparency blocked (Photoshop)

  • August 9, 2026
  • 1 reply
  • 2 views

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).

    1 reply

    rob art | illustration
    Known Participant
    August 9, 2026

    Setup: a minimal UXP panel plugin (manifest v5, host PS). Panel HTML:

     

    <div style="position:relative; height:200px; background:#FFFF88;">

    <!-- a coloured layer we want to show THROUGH the textarea -->

    <div style="position:absolute; inset:0; background:

    repeating-linear-gradient(transparent, transparent 17px, #db7777 17px, #db7777 18px);

    pointer-events:none;"></div>

    <textarea style="position:absolute; inset:0; width:100%; height:100%;

    background:transparent; border:none; color:#333;"></textarea>

    </div>

    Steps:

    1. Load the plugin in Photoshop (via UXP Developer Tool) and open its panel.
    2. Observe the <textarea>, which has background: transparent.

    Expected: the textarea is transparent, so the yellow background + red ruled lines behind it show through (as it did in earlier Photoshop/UXP versions).

    Actual: the textarea renders as a solid dark block (the host theme background). The background: transparent is ignored; nothing behind the textarea is visible. Typing still works, but the field is opaque-dark.

    Also observed (optional, shows it's not a one-off):

    • Setting background: rgba(255,255,136,0.01) → still a solid dark block.
    • Setting background-color: #FFFF88 (opaque) → renders correctly (yellow). So only transparency is affected.
    • -webkit-appearance:none !important / appearance:none !important → no effect.
    • Same result for <input> and <sp-textarea>.

    Environment: PS release <x>, PS Beta <x> (reproduces in both), UXP <x>, macOS <x>, manifest v5.

    practice safe design | use a concept~ Petrula Vrontikis