Skip to content

fix(ui): give modal panels a width prop and restore the widths lost to it - #988

Merged
wibus-wee merged 1 commit into
mainfrom
fix/dialog-content-width-prop
Sep 26, 2026
Merged

wibus-wee merged 1 commit into
mainfrom
fix/dialog-content-width-prop

Conversation

@wibus-wee

Copy link
Copy Markdown
Member

Summary

  • @lody/ui's ModalContentProps gains a width prop (shared by Dialog.Content and AlertDialog.Content), merged onto the popup's inline style by mergePanelWidth — object and state-callback style forms both compose.
  • Restores the panel widths silently clamped to 512px by the @lody/ui migration: a lone max-w-* can only narrow the fixed width: 512px token, never widen it. Paste preview 48rem, usage share image 56rem, file quick-open / failed detail / operation reply 42rem, machine pairing 36rem.
  • Unifies every surviving non-default panel width onto the prop: chat-failed-detail, session-file-preview, chat-share-image, update-changelog, open-source-attributions, skill-detail, and SETTINGS_EDITOR_DIALOG_WIDTH (620px, split out of SETTINGS_EDITOR_DIALOG_LAYOUT).
  • Inline style beats the panel's StyleX width regardless of sheet order and never displaces the rung's max-width: calc(100vw - 32px) viewport cap, so narrow windows still bound the panel.
  • The cmdk palette keeps 512px (intentional post-rework); Drawer keeps drawerSize.
  • test/dialog.test.tsx pins the contract; components/src/ui/AGENTS.md documents width as the one way to state a non-default panel width; decision note in .agents/notes/implemented/bug-fix/2026-09-25-dialog-content-width-prop.md (+ zh).

Test plan

  • pnpm --filter @lody/ui test (new test asserts width lands as inline style and composes with caller style)
  • pnpm check + pnpm format — not runnable in this nested checkout (deps not installed); please run before merge
  • Visual: open the affected dialogs (paste a large text block, usage share card, file quick-open, machine pairing, operation reply) and confirm restored widths

Generated with Devin

@wibus-wee
wibus-wee force-pushed the fix/dialog-content-width-prop branch 2 times, most recently from fff9f39 to 56d1c8c Compare September 26, 2026 07:37
…o it

The @lody/ui migration replaced the fluid w-[calc(100vw-4rem)] + max-w-lg
panel with a fixed width: 512px StyleX declaration. Every dialog that had
widened itself with a lone max-w-* was silently clamped back to 512px,
because max-width can only narrow a fixed width, never raise it — the paste
preview (48rem), usage share image (56rem), file quick-open and the failed
detail and operation reply panels (42rem), and machine pairing (36rem) all
shrank. A w-* class could still win by cascade-layer order, but depending
on sheet order for the one layout dial a panel offers is exactly the trap
that shipped this.

ModalContentProps now takes width, merged onto the popup's inline style by
mergePanelWidth whether the caller's style is an object or a state callback.
Inline style always follows the panel and never displaces the rung's own
100vw-32px viewport cap. Every non-default panel width — restored ones and
the surviving w-[calc()]/style{{width}} spellings — goes through it, and
SETTINGS_EDITOR_DIALOG_LAYOUT splits its 620px out to the prop. The cmdk
palette keeps 512px on purpose.

Generated with [Devin](https://devin.ai)

Co-Authored-By: Devin <158243242+devin-ai-integration[bot]@users.noreply.github.com>
Model: swe-2-high
@wibus-wee
wibus-wee force-pushed the fix/dialog-content-width-prop branch from 56d1c8c to 666980d Compare September 26, 2026 07:59
@wibus-wee
wibus-wee marked this pull request as ready for review September 26, 2026 08:13
@wibus-wee
wibus-wee merged commit ab00627 into main Sep 26, 2026
7 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant