Skip to content

Fix invisible context menus and confirm dialogs (transparent panel background) - #433

Merged
epeicher merged 1 commit into
trunkfrom
deskmod-61-fix-invisible-contextual-menu-items-in-my-wordpress
Jul 28, 2026
Merged

Fix invisible context menus and confirm dialogs (transparent panel background)#433
epeicher merged 1 commit into
trunkfrom
deskmod-61-fix-invisible-contextual-menu-items-in-my-wordpress

Conversation

@epeicher

@epeicher epeicher commented Jul 28, 2026

Copy link
Copy Markdown
Collaborator

What it does

Restores the opaque dark panel behind <wpd-context-menu>, <wpd-confirm-dialog>, and <wpd-modal>. All three currently render fully transparent — right-clicking a tile in My WordPress shows the menu items as loose white text floating over the window body, and the delete-confirmation prompt is equally unreadable.

Before After
CleanShot 2026-07-28 at 10 46 54@2x CleanShot 2026-07-28 at 12 54 36@2x

Rationale

The desktop-themes texture work (#420) added a texture-slot longhand immediately after each surface's background: shorthand:

background: var( --wpd-context-menu-bg, var( --desktop-mode-bg, #1d2327 ) );
background-image: var( --wpd-menu-bg-image, none ); /* texture slot */

--desktop-mode-bg is the wallpaper token and holds a gradient — an <image>, not a <color>. The shorthand therefore routed the entire paint into background-image (leaving background-color: transparent), and the texture slot's none fallback then wiped that image out. With no desktop theme active, nothing painted at all.

#420 converted other surfaces from background: to background-color for exactly this shorthand-resets-the-texture reason; these three were missed because their fallback chain bottoms out in the gradient rather than a color literal.

Implementation

Each surface now splits the paint into its two longhands, so the texture slot owns background-image outright:

background-color: var( --wpd-context-menu-bg, #1d2327 );
background-image: var( --wpd-menu-bg-image, none );

--desktop-mode-bg leaves the chain deliberately: an image-valued token can never feed background-color, and keeping it as the texture slot's fallback would paint the default gradient over any theme-set surface color (the :root gradient is always defined). The literal #1d2327 matches the gradient's base tone, so the default look is unchanged apart from losing an imperceptible tint sweep. A comment at each site documents the constraint.

Testing instructions

  1. npm run env:start, then in the desktop shell open My WordPress → Media (any section with tiles works).
  2. Right-click a tile — the context menu must render on an opaque dark panel with white items and a red Delete permanently.
  3. Pick Delete permanently — the confirmation dialog must render the same opaque panel; Cancel dismisses it.
  4. npm run test:js (2353 tests), npm run lint, npm run typecheck — all green.

…m dialogs

The desktop-themes texture slots added a background-image longhand
right after each surface's background: shorthand. These three
surfaces resolve their color through --desktop-mode-bg, which holds
the wallpaper GRADIENT — an <image>, not a <color> — so the shorthand
routed the whole paint into background-image, and the texture slot's
`background-image: var(--slot, none)` then reset it to nothing. With
no desktop theme active the panels rendered fully transparent: white
menu items floating unreadably over the My WordPress window body.

Split the paint into longhands, matching the conversion the texture
work applied elsewhere: background-color carries the surface token
with a literal dark fallback, and background-image stays owned by
the texture slot. --desktop-mode-bg leaves the chain — an image-
valued token can never feed background-color, and keeping it in the
texture slot's fallback would paint over theme-set surface colors.
@epeicher
epeicher enabled auto-merge (squash) July 28, 2026 10:55
@epeicher
epeicher merged commit 8e72b05 into trunk Jul 28, 2026
5 checks passed
@epeicher
epeicher deleted the deskmod-61-fix-invisible-contextual-menu-items-in-my-wordpress branch July 28, 2026 10:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant