- Ya
- 24 Agosti 2026, 20:56 UTC
- Mwandishi
- kamo
- Ahadi ya
- 9e67f0a
The drop target was the composer surface alone — a few dozen pixels at the bottom of a window that is otherwise all messages. A screenshot let go over the conversation did nothing at all, and worse: the browser's default for an unclaimed file drop is to NAVIGATE the tab to the file, which takes every open tool window and every unsent draft with it. `useComposerIngest` gains `bindDropTarget`, which binds the drag gestures to an element the composer does not own, and `ComposerSurface` resolves that element from the DOM — the shell's own `data-tool-window`, or `data-chatbox-root` for a chat that draws its own frame. Native listeners in the CAPTURE phase, so nothing inside the window can take the gesture first or stop it short before the window has seen it; only drags carrying files are claimed, so the AI chat's folder tree keeps its own drag-and-drop untouched. A file drag is claimed even while attaching is locked — refusing the file must not cost the member the page. One ingest per composer still, so the window and the surface can never stage the same drop twice. Member chat, support tickets, social conversations, AI chat and SMS all get this from the one surface they share; a composer with no window around it keeps the old behaviour.