Replies: 1 comment
|
The case that hurts most is dragging a fresh screenshot from the macOS thumbnail in the corner of my desktop. The thumbnail disappears after a few seconds, so the drag has to be fast. Rushed like that, I miss the small input box more often than I hit it. I see no reason why the whole area around the input should not accept the drop. |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Area
apps/web
Problem or use case
Dragging an image onto the text input attaches it. Dropping it elsewhere in the active workspace does nothing, even though the current thread is the clear destination.
Proposed solution
The drop zone should cover the active workspace: everything below the window chrome and to the right of the left sidebar. Dropping an image anywhere in that area should attach it to the current thread. The chrome and sidebar should keep their existing drag behavior.
Why this matters
The current drop target is unnecessarily small, so valid image drops are easy to miss.
Smallest useful scope
Expand the existing image drop target in the shared web and desktop workspace. Keep the current image types, limits, and validation.
Alternatives considered
I can use the upload button or aim directly at the text input, but both are slower than dropping into the active workspace.
Risks or tradeoffs
The larger target should not intercept dragged text, links, or files outside the active workspace.
Examples or references
#1790 confirms that image drag and drop already exists. This request only expands its drop target.
Contribution
All reactions