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>
