[base-styles] Bump .components-draggable__clone z-index above wp compat overlay slot#78177
[base-styles] Bump .components-draggable__clone z-index above wp compat overlay slot#78177ciampo wants to merge 1 commit into
Conversation
…t overlay slot The `@wordpress/ui` compat overlay slot introduced in #77851 sits at z-index `1000000003`. Once `@wordpress/ui` overlays (Tooltip, etc.) portal into that slot, an active drag at `1000000000` would render *below* any popup that's mid-flight. Bump the clone to `1000000004` so it stays above the slot. This is the surgical fix. A larger follow-up could migrate `.components-draggable__clone` onto the slot itself, which would eliminate the z-index race entirely.
|
Size Change: +5 B (0%) Total Size: 7.93 MB 📦 View Changed
ℹ️ View Unchanged
|
|
Flaky tests detected in 99fa05a. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/25682989492
|
Something tells me that it's better to just do that cleaner migration than to do a temporary z-index change 🤔 If we do the clean fix it's clean from now on, whereas if we change the z-index now, we'll forever have to deal with the fact that the draggable clone can have two different z-indexes depending on the version, and it's not even clean yet. Basically three possible states to think about rather than two. What do you think? |
What?
Bump
.components-draggable__clonefrom1000000000to1000000004inpackages/base-styles/_z-index.scss. The new value sits one above the@wordpress/uicompat overlay slot (1000000003) introduced in #77851.Dependency: this PR is meaningful only once #77851 lands. Marked Draft for that reason.
Why?
Once
@wordpress/uioverlays (Tooltip first, in #78095) start portaling into the compat slot at1000000003, an active drag at1000000000would render below any popup that's mid-flight. Bumping the clone keeps the existing "drag stays above the entire UI" invariant — including above the new slot.How?
One-line literal swap on the legacy z-index map, plus a comment that calls out the slot relationship:
Alternative considered
The cleaner direction is to migrate
.components-draggable__cloneonto the compat overlay slot itself (or its own slot at the same stacking band), which would eliminate the z-index race rather than push it one rung higher. That's a larger refactor across the draggable-clone rendering pipeline; this PR opts for the surgical fix so the migration can happen separately and on its own schedule.Testing Instructions
@wordpress/componentsDraggable instance and a@wordpress/uiTooltip simultaneously in the editor.Next steps
.components-draggable__cloneto its own slot so its z-index doesn't need to chase the compat slot.Use of AI Tools
Authored with Cursor (Claude). Author reviewed all changes.