Kaede AkinoandClaude Opus 5
68dee1137d
On the Assistant page, dragging a file onto the sidebar attached it to `window.sidebar.assistantDraft` — the Workspace sidebar's new-chat draft, which is not on screen there, so the file appeared to vanish. `AssistantPanelView` already declared the intent with `isEnabled: isFocusedOnWorkspace`, but the flag never reached AppKit. `FileURLDropNSView` registered its dragged types unconditionally in `init` and never unregistered, and only `hitTest` consulted `isEnabled` — the three dragging callbacks did not. A view that refuses the hit test but stays in the window's registered destination list still wins the drop. This is the asymmetry `AssistantConversationListContainer.isInteractive` records for conversation drags; the shared file receiver had only the hit-test half. Give it both: follow `isEnabled` when registering and unregistering, and gate `supportedPayload(from:)`, the one chokepoint `hitTest` and all three callbacks pass through. The callbacks already treat a nil payload as "not mine", so their bodies are unchanged. The second half is what holds when `isEnabled` flips during a drag already in flight, after AppKit has resolved its destinations. Fixing the shared view also covers two sites with the same flaw: hidden Workspaces, which all stay mounted at `opacity(0)` over the same frame carrying a pane drop target, and Keychain accepting drops mid-load. `FileURLDropTargetTests` becomes `.serialized` — every test there stages its case on the one drag pasteboard the system shares, and the suite was already racing with itself before these two tests made it fail. Verification: macOS build, full test suite (remaining failures match the clean-tree baseline and are unrelated), swift-format lint adds nothing new, and Scripts/check-zh-localization.sh passes. The end-to-end Finder drag is still to be confirmed by hand. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>