Ensure Settings opens above active edit popovers

[AmyShang-alt]

Summary

Settings can open behind the edit popover when an edit modal is already active.

Current behavior

After opening an edit popover on the canvas, clicking the Settings button opens the Settings modal underneath the existing edit popover instead of bringing Settings to the front.

This creates an incorrect layer order:

• The edit popover remains visually above Settings.
• The Settings surface is partially or fully hidden behind the edit popover.
• Users can trigger Settings, but the UI does not clearly show the newly requested modal as the active top-level surface.

Expected behavior

When the user clicks Settings, the Settings modal should become the active topmost layer.

Possible acceptable behaviors:

• Settings opens above the edit popover.
• Or the edit popover closes/dismisses before Settings opens.

In either case, Settings should not appear underneath an existing edit popover.

Steps to reproduce

1. Open a project in Open Design.
2. Enter the visual editor/preview editing mode.
3. Click an editable element so the edit popover opens.
4. Without closing the edit popover, click the Settings button.
5. Observe the layer order.

Notes

Observed in the attached/local screen recording: 20260617120917_rec_.mp4.

The issue appears to be a modal/popover stacking order problem between the canvas edit popover and the global Settings modal.

Why this matters

Settings is a global app surface and should have predictable priority when opened. If it appears behind an edit popover, users may think Settings failed to open or may be blocked by a stale editing layer.

[lefarcen]

If you want to take this on, comment /claim and we can assign it to you.

[maxmilian]

I took a look at this and couldn't reproduce the layer order on current main — Settings opened above the canvas popovers I tried, so sharing what I checked in case it helps narrow it down.

What I tried (1440×900, headless Chromium against a mock daemon):

• Open a design file → open the Share popover in the file toolbar → open Settings. The Settings backdrop ends up on top: document.elementFromPoint over the share popover's centre lands on the Settings modal, not the popover.

Looking at the stacking to explain why: the share/present popover does carry z-index: 220, but it's confined inside .ws-tabs-shell (position: sticky; z-index: 4), so it never actually rises above the modal backdrop (z-index: 100). The manual-edit inspector (.manual-edit-right) is z-index: 30 inside a workspace that isn't elevated in edit mode, so it sits below the backdrop too. I couldn't find a canvas edit popover that lands above Settings.

Could you confirm whether you still see this on a fresh build, and which specific edit popover bled through? The screen recording (20260617120917_rec_.mp4) would help pinpoint the exact surface so a fix can target it.

[lefarcen]

Thanks for digging into this, @maxmilian — that’s helpful context.

On current main, the code shape lines up with what you saw: .modal-backdrop is z-index: 100, .ws-tabs-shell is z-index: 4, and the manual edit rail in viewer/memory.css is z-index: 30, so neither of those surfaces should be able to sit above Settings. PR #4193 also recently fixed one workspace-tab popover layering case, so this may be either an already-fixed path or a more specific canvas-only popover than the ones checked so far.

@AmyShang-alt, could you retry this on a fresh main build and call out the exact popover from 20260617120917_rec_.mp4 if it still reproduces? The smallest missing detail is whether this was the right-side manual edit panel, the page-card variant, the color picker inside it, or another canvas-only popover — that should tell us whether there’s still an open bug to fix here.

[lefarcen]

Quick follow-up on this one: PR #4193 has now shipped a related z-index fix on main, and together with @maxmilian's check it makes this look more like either an already-fixed path or a narrower canvas-only popover case than the original report described.

@AmyShang-alt, if a fresh main build no longer reproduces it, feel free to close this out. If it still does, the one detail we still need is the exact surface from 20260617120917_rec_.mp4 that stayed above Settings — for example the right-side manual edit rail, the page-card variant, the color picker inside it, or another canvas-only popover.

[xxiaoxiong]

/claim

[lefarcen]

Thanks for picking this up, @xxiaoxiong! Appreciate it.

Roughly how long do you think it’ll take — a few hours, 1–3 days, about a week, or longer?

[lefarcen]

PR #5091 is now up for this: it raises the shared dialog backdrop above the current popover tiers (100 → 2000) and keeps the privacy consent banner just above it (110 → 2010), which matches the layer-order failure described here.

Keeping this issue open until the PR lands and the fix is verified.

[lefarcen]

Hey @xxiaoxiong, PR #5091 has been quiet for a bit — anything you want feedback on, or are you mid-iteration?