feat(desktop): drop files anywhere in the chat area#36262
Merged
Conversation
File drops were only wired to the composer input. Add a reusable useFileDropZone hook (enter/leave depth counting + capture-phase reset so the affordance clears even when the composer claims the drop) and a pointer-events-none ChatDropOverlay, wired onto the conversation viewport. Drops funnel through the existing onAttachDroppedItems; composer drops keep their own inline-ref behavior.
Contributor
🔎 Lint report:
|
…t cards Match the composer-input drop behavior — funnel dropped paths through droppedFileInlineRef + the composer insert bus so they render as inline ref chips instead of attachment cards.
vision_analyze reports its input image as a local filesystem path, which toolImageUrl handed straight to <img src>. In the renderer that resolves against the dev-server origin and 404s. Restrict inline tool images to fetchable sources (data: URLs and remote http(s)); bare paths now fall back to the tool's codicon.
3 tasks
JoeKowal
pushed a commit
to JoeKowal/hermes-agent
that referenced
this pull request
Jun 4, 2026
* feat(desktop): drop files anywhere in the chat area File drops were only wired to the composer input. Add a reusable useFileDropZone hook (enter/leave depth counting + capture-phase reset so the affordance clears even when the composer claims the drop) and a pointer-events-none ChatDropOverlay, wired onto the conversation viewport. Drops funnel through the existing onAttachDroppedItems; composer drops keep their own inline-ref behavior. * fix(desktop): chat-area drops insert inline @file refs, not attachment cards Match the composer-input drop behavior — funnel dropped paths through droppedFileInlineRef + the composer insert bus so they render as inline ref chips instead of attachment cards. * fix(desktop): don't render bare file paths as tool images (404) vision_analyze reports its input image as a local filesystem path, which toolImageUrl handed straight to <img src>. In the renderer that resolves against the dev-server origin and 404s. Restrict inline tool images to fetchable sources (data: URLs and remote http(s)); bare paths now fall back to the tool's codicon.
1 task
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Two desktop chat fixes.
1. Drop files anywhere in the chat area
useFileDropZonehook: enter/leave depth counter (no flicker over nested children) + a capture-phaseonDropCapturereset so the affordance always clears — even when the composer claims a drop andstopPropagations before the bubble-phaseonDropruns.ChatDropOverlay: full-bleed,pointer-events-none(the drop lands on the real element underneath), styled to mirror the composer surface.@file:ref chips the composer-input drop produces (not attachment cards), viadroppedFileInlineRef+ the composer insert bus. Composer drops keep their own caret-aware behavior. Disabled while a session is still loading.2. Don't render bare file paths as tool images (404)
vision_analyze(and any tool reporting an image by local path) rendered a broken/404 image:toolImageUrlhanded the bare filesystem path straight to<img src>, which resolves against the renderer origin → 404.data:URLs + remotehttp(s)); bare paths fall back to the tool's codicon. Regression tests viabuildToolView.Test plan
tsc -b+ eslint clean on changed filesvitest run tool-fallback-model.test.ts— 3 passednpm run dev(HMR)vision_analyzeon a local image → tool codicon, no broken image