Summary

In v2.36.0 the workspace Change version dialog renders its template-version list behind the dialog itself. Only the options that overflow past the dialog's bottom edge are visible, and the currently-active version row is occluded and unclickable.

Still present in v2.36.1 and on main.

Steps to reproduce

1. Run a self-hosted deployment on v2.36.0 or v2.36.1 (Kubernetes, official Helm chart).
2. Open any workspace with more than a couple of successful template versions.
3. More -> Change version.
4. Click the version combobox to expand it.

Expected: the option list renders above the dialog and every option is visible and clickable.

Actual: the list is painted underneath the dialog. Only the portion extending past the dialog's bottom edge is visible; the top of the list, including the row carrying the Active pill, is hidden behind the dialog body.

Cause

v2.36.0 changed the picker in site/src/modules/workspaces/WorkspaceMoreActions/ChangeWorkspaceVersionDialog.tsx from an MUI Autocomplete (used through 2.35.x, rendered inside the dialog's own DOM) to the Radix Popover-based Combobox:

The two pieces then disagree about stacking:

• PopoverContent in site/src/components/Popover/Popover.tsx hardcodes z-50 and renders into PopoverPrimitive.Portal, so the list is appended to document.body and escapes the dialog's stacking context.
• The enclosing ConfirmDialog is still MUI-based. site/src/components/Dialogs/Dialog.tsx re-exports MuiDialog as Dialog, and ConfirmDialog.tsx imports both that re-export and MUI's DialogActions. chore(site): migrate all <Dialog />s off MUI #27506 ("migrate all <Dialog />s off MUI") did not cover this one.
• There is no zIndex override under site/src, so MUI's default theme.zIndex.modal = 1300 applies.

Both elements are children of document.body, and 50 < 1300, so the dialog paints over the popover.

Suggested fix

The minimal fix is to render the popover inside the dialog's stacking context. PopoverContent already supports this and ComboboxContent spreads ...props straight through, so it is a one-word change at the call site:

   <ComboboxContent
+    disablePortal
     className="max-w-none min-w-[min(100%,320px)]"
     align="start"
   >

One caveat with that approach: rendering inline can get clipped by the dialog paper's overflow, so it may be worth checking against a long version list.

The more durable fix is probably to raise PopoverContent above MUI's modal z-index (or lower theme.zIndex.modal) while the MUI -> Radix migration is in progress, since any MUI dialog that adopts the new Combobox will hit this same mismatch. #27723 migrated WorkspacesButton to Combobox and there appear to be more of these planned.

Notes

This change does not appear in the v2.36.0 release notes under BREAKING CHANGES, Features > Dashboard, or Bug fixes > Dashboard, so it is easy to miss when triaging an upgrade.

Environment

• Coder v2.36.0 and v2.36.1 (official Helm chart, Kubernetes)
• OSS/AGPL, no Premium features enabled
• Reproduced in Chromium and Firefox, dark theme