[BUG] Photoshop 27.9.1 — UXP panel native Spectrum widgets non-interactive due to CSS clipping regression

1. Summary

In Photoshop 27.9.1, native Spectrum widgets (sp-textarea / sp-textfield) placed inside an ancestor container with overflow: hidden; height: 0 (a common CSS trick used to visually crop/round native widget corners) become completely non-interactive.

• ❌ Symptom: No cursor, no focus state, no keyboard input, and placeholder text disappears.

• 🔄 Regression: The exact same markup and CSS worked perfectly in Photoshop 27.8 and prior.

• 💡 Scope: Only native Spectrum widgets are affected; standard HTML <textarea> / <input> elements continue to work under the same CSS layout.

2. Environment

• Photoshop Version: 27.9.1 (Broken) vs 27.8 (Working)

• OS: Windows (Confirmed)

• Extensibility Platform: UXP Panel

• Affected Widgets: <sp-textarea>, <sp-textfield>

3. Root Cause Analysis

The plugin utilizes a .crop wrapper to clip and offset native inputs:

CSS

.crop { position: relative; width: 100%; overflow: hidden; height: 0; } 

The child (sp-textarea) is absolutely positioned with a negative top offset (top: -2px) to visually escape the zero-height container.

• In 27.8 (Expected Behavior): Native Spectrum widgets were composited by the host outside normal DOM clipping boundaries. The widget's own render layer successfully ignored the ancestor's overflow: hidden, remaining visible and interactive.

• In 27.9.1 (Regression): The native widget is now strictly bound by the ancestor's DOM clip region. While it remains present in the DOM (document.getElementById still resolves it and styles report normally), it becomes invisible/non-interactive as it is effectively clipped out of existence.

4. Steps to Reproduce

1. Create a minimal UXP panel with the following structure:

HTML

<div class="bg"> <div class="crop" style="position: relative; overflow: hidden; height: 0;"> <sp-textarea style="position: absolute; top: -2px; left: -2px; height: 69px;"></sp-textarea> </div> </div> 

1. Test in Photoshop 27.8: Click the textarea. Focus is acquired, cursor appears, and typing works normally.

2. Test in Photoshop 27.9.1: Click the textarea. Focus is not acquired, no cursor appears, and el.value remains empty.

3. Isolate: Remove the .crop { height: 0; overflow: hidden; } styling on 27.9.1. The sp-textarea immediately regains full interactivity—confirming the container's clip pattern is the sole trigger.

5. Applied Workaround (For other developers facing this)

To restore functionality on 27.9.1 without refactoring the entire UI layout:

1. Replaced <sp-textarea> / <sp-textfield> with native HTML <textarea> / <input> elements.

2. Removed overflow: hidden from the .crop container (keeping height: 0 since the absolute positioning math relied on it).

6. Secondary Platform Observations (Related to UXP Custom Engine)

During troubleshooting, we also confirmed/re-verified several UXP-specific engine limitations in 27.9.1:

• Unsupported CSS: scrollbar-width, ::-webkit-scrollbar (and its pseudo-elements), and position: fixed do not composite reliably.

• Rendering Glitch: Setting a transparent or low-alpha background-color on native-replaced text fields intermittently fails to repaint, causing visible flicker or stale rendering. Only fully opaque background colors repaint reliably.

• Scrollbar Behavior Change: Overflowing textareas default to no scrollbar in 27.8, but render a visible scrollbar with up/down arrows in 27.9.1. This appears to be an unexposed default behavior of the updated rendering engine.

7. Actionable Ask to Adobe / UXP Team

• Can you please confirm if this compositing/clipping behavior change for native Spectrum widgets in Photoshop 27.9.1 is an intentional design change or an unintended side effect of the host's rendering engine update?

• If it is a regression, are there plans to align native widget compositing back to the 27.8 behavior in an upcoming patch? This silently breaks existing plugins relying on this common clipping container pattern.