Drag and drop files does not work in right/bottom areas with >100% DPI scaling #6413

Open
opened 2026-01-31 00:37:56 +00:00 by claunia · 0 comments
Owner

Originally created by @jingyu9575 on GitHub (Feb 13, 2020).

Environment

Windows build number: 10.0.18363.0
Windows Terminal version (if applicable): 0.9.433.0

Any other software?: No

Steps to reproduce

  1. In Windows display settings, select 150% DPI scaling;
  2. Drag a file to the terminal, at the bottom or right inside the window.

Expected behavior

Tooltip shows "copy path to file". The file path is inputed.

Actual behavior

Nothing. Tooltip shows "🚫". This screenshot was made with a CI build right after drag/drop was implemented, but the same behavior happens in today's release.

On my system with 150% DPI scaling, the size of the acceptable area seems to be 1/(150%) of the window (similar to #2606). Also, some bottom area in the tabs is (incorrectly) acceptable to drops, and the height seems to be also 1/(150%) of the tab bar. Therefore I suspect some code is checking the acceptable area but is missing a DPI/96 factor.

Screenshot

Originally created by @jingyu9575 on GitHub (Feb 13, 2020). <!-- 🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨 I ACKNOWLEDGE THE FOLLOWING BEFORE PROCEEDING: 1. If I delete this entire template and go my own path, the core team may close my issue without further explanation or engagement. 2. If I list multiple bugs/concerns in this one issue, the core team may close my issue without further explanation or engagement. 3. If I write an issue that has many duplicates, the core team may close my issue without further explanation or engagement (and without necessarily spending time to find the exact duplicate ID number). 4. If I leave the title incomplete when filing the issue, the core team may close my issue without further explanation or engagement. 5. If I file something completely blank in the body, the core team may close my issue without further explanation or engagement. All good? Then proceed! --> <!-- This bug tracker is monitored by Windows Terminal development team and other technical folks. **Important: When reporting BSODs or security issues, DO NOT attach memory dumps, logs, or traces to Github issues**. Instead, send dumps/traces to secure@microsoft.com, referencing this GitHub issue. If this is an application crash, please also provide a Feedback Hub submission link so we can find your diagnostic data on the backend. Use the category "Apps > Windows Terminal (Preview)" and choose "Share My Feedback" after submission to get the link. Please use this form and describe your issue, concisely but precisely, with as much detail as possible. --> # Environment ```none Windows build number: 10.0.18363.0 Windows Terminal version (if applicable): 0.9.433.0 Any other software?: No ``` # Steps to reproduce <!-- A description of how to trigger this bug. --> 1. In Windows display settings, select 150% DPI scaling; 2. Drag a file to the terminal, at the bottom or right inside the window. # Expected behavior <!-- A description of what you're expecting, possibly containing screenshots or reference material. --> Tooltip shows "copy path to file". The file path is inputed. # Actual behavior <!-- What's actually happening? --> Nothing. Tooltip shows "🚫". This screenshot was made with a CI build right after drag/drop was implemented, but the same behavior happens in today's release. On my system with 150% DPI scaling, the size of the acceptable area seems to be `1/(150%)` of the window (similar to #2606). Also, some bottom area in the tabs is (incorrectly) acceptable to drops, and the height seems to be also `1/(150%)` of the tab bar. Therefore I suspect some code is checking the acceptable area but is missing a `DPI/96` factor. ![Screenshot](https://user-images.githubusercontent.com/8923139/73556567-f747bb80-444f-11ea-98e4-51f8114e1162.gif)
claunia added the Resolution-Duplicate label 2026-01-31 00:37:56 +00:00
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#6413