[Bug]: Long thread titles overflow the delete confirmation dialog

[saphid]

In T3 Code v1, deleting a thread whose title is a long URL renders the title outside the confirmation dialog. Reproduced on upstream main 93e0416 in the web client using the URL-shaped title from the report: the heading has a scroll width of 563px in a 462px content area. At 390px viewport width the text extends beyond the screen. Expected: the complete confirmation title wraps within the dialog, with Cancel and Confirm remaining accessible.

[juliusmarminge]

Triage

Confirmed on current main (dfbb11bdd). The heading overflow reported at 93e04160a0 is still present: ConfirmDialogHost and AlertDialogTitle did not change in a way that would wrap an unbreakable title. I did not find a duplicate.

What happens

Web and desktop delete confirmation always interpolates the full thread title into the confirm message:

              `Delete thread "${title}"?`,
              "This permanently clears conversation history for this thread.",
            ].join("\n"),

The same copy is used from useThreadActionMenu, Sidebar, and LegacySidebar. All of them go through localApi.dialogs.confirm → ConfirmDialogHost.

resolveConfirmDialogCopy treats the line that ends in ? as the dialog title, so a URL-shaped title becomes the heading. That heading is rendered with no wrap constraint:

      <AlertDialogPopup className="max-w-lg">
        <AlertDialogHeader>
          <AlertDialogTitle>{copy.title}</AlertDialogTitle>

function AlertDialogTitle({ className, ...props }: AlertDialogPrimitive.Title.Props) {
  return (
    <AlertDialogPrimitive.Title
      className={cn("font-heading font-semibold text-xl leading-none", className)}
      data-slot="alert-dialog-title"
      {...props}
    />
  );
}

The popup already has min-w-0 w-full max-w-lg, so the dialog box stays at ~462px of content width. The title does not: a long URL has no break opportunity under the default wrap rules, so scrollWidth grows (563px in the report) and the text paints outside the dialog. At a 390px viewport that heading extends past the screen. Cancel and Confirm stay in the footer, but the confirmation question is no longer readable in-bounds.

This is display-only. Delete still works if the user can reach the buttons.

Surfaces

• Web / desktop: shared ConfirmDialogHost. Desktop is the same web dialog.
• Mobile: not this bug. useConfirmDeleteThread uses the short title Delete thread? and puts “${thread.title}” will be permanently deleted… in the message body (native Alert on iOS).

Other web alert titles that interpolate user-controlled names (Delete action "…", theme/profile names) have the same heading primitive and would overflow the same way.

Related work

Item	Relevance
#11443 / #11446 (open)	Same class of bug: an unbreakable string overflows a max-w-lg dialog. That ticket is the Add Action textarea, not this title. Their proposed fix is min-w-0 + wrap-anywhere.
#5624 (merged)	Introduced the themed confirm dialogs this title lives in.
#6392 (closed)	Commit-dialog path overflow. Different surface.

Not marking as a duplicate of #11443. Fixing the textarea does not wrap this heading.

Recommended direction

Keep the full title visible. Do not truncate it.

Smallest fix: give AlertDialogTitle min-w-0 wrap-anywhere (or [overflow-wrap:anywhere]) in apps/web/src/components/ui/alert-dialog.tsx, so every confirmation that interpolates a name wraps inside the dialog. Putting it on the primitive is better than a one-off class on ConfirmDialogHost.

Optional, still in scope if you want the same protection elsewhere:

• AlertDialogDescription for a long second line.
• DialogTitle in dialog.tsx uses the same heading classes.

Do not move the thread name into the description as the only fix. The reported success criterion is that the complete confirmation title wraps in the dialog and Cancel / Confirm stay accessible.

A focused test that opens the confirm host with a long URL title and asserts the heading scrollWidth <= clientWidth (or that the title carries the wrap class) would lock this in. No newer release has this fix.