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

Activity

1. juliusmarminge commented on Sep 19, 2026

   

   juliusmarminge

   on Sep 19, 2026

   Member

   More actions

   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.
2. juliusmarminge

   added

   acceptedfeature request acceptedfeature request accepted

   bugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   on Sep 19, 2026
3. juliusmarminge

   closed this as completedin #12571on Sep 19, 2026