Drag & Drop folder on Windows Terminal problems with Window screen scaling (HDPI) #11791

Closed
opened 2026-01-31 02:57:31 +00:00 by claunia · 4 comments
Owner

Originally created by @warpdesign on GitHub (Dec 12, 2020).

Environment

Windows build number: Microsoft Windows [version 10.0.19042.685]
Windows Terminal version (if applicable): 1.4.32.43.0

Steps to reproduce

  • Set Windows display scaling to 200% (I am using a Surface Book: this is the default scaling: I never changed it)
  • Open a Windows Terminal Window
  • Try to drag and drop a folder from Windows Explorer to the Windows Terminal Window

Expected behavior

Dropping the folder anywhere in the Terminal window should work.

Actual behavior

It only works in the upper left area of the window: dropping on the right/bottom of the window isn't allowed.

Note: the area where the drop works appears to correspond to the size of the window without the Window scaling. Disabling the Windows screen scaling makes the drop area work as expected.

Video: https://www.youtube.com/watch?v=Cs9bf-yAzRg

As you can see: depending on the position of the dragged element inside the Terminal window, drag & drop is allowed or forbidden.

Originally created by @warpdesign on GitHub (Dec 12, 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: Microsoft Windows [version 10.0.19042.685] Windows Terminal version (if applicable): 1.4.32.43.0 ``` # Steps to reproduce - Set Windows display scaling to 200% (I am using a Surface Book: this is the default scaling: I never changed it) - Open a Windows Terminal Window - Try to drag and drop a folder from Windows Explorer to the Windows Terminal Window <!-- A description of how to trigger this bug. --> # Expected behavior Dropping the folder anywhere in the Terminal window should work. <!-- A description of what you're expecting, possibly containing screenshots or reference material. --> # Actual behavior It only works in the upper left area of the window: dropping on the right/bottom of the window isn't allowed. Note: the area where the drop works appears to correspond to the size of the window without the Window scaling. Disabling the Windows screen scaling makes the drop area work as expected. Video: https://www.youtube.com/watch?v=Cs9bf-yAzRg As you can see: depending on the position of the dragged element inside the Terminal window, drag & drop is allowed or forbidden.
claunia added the Resolution-ExternalNeeds-Tag-Fix labels 2026-01-31 02:57:31 +00:00
Author
Owner

@DHowett commented on GitHub (Dec 13, 2020):

Thanks for the report. Unfortunately, we've traced this back to a platform limitation. I know, that sucks.

/dup https://github.com/microsoft/microsoft-ui-xaml/issues/2101

@DHowett commented on GitHub (Dec 13, 2020): Thanks for the report. Unfortunately, we've traced this back to a platform limitation. I know, that sucks. /dup https://github.com/microsoft/microsoft-ui-xaml/issues/2101
Author
Owner

@ghost commented on GitHub (Dec 13, 2020):

Hi! We've identified this issue as a duplicate of one that exists on somebody else's Issue Tracker. Please make sure you subscribe to the referenced external issue for future updates. Thanks for your report!

@ghost commented on GitHub (Dec 13, 2020): Hi! We've identified this issue as a duplicate of one that exists on somebody else's Issue Tracker. Please make sure you subscribe to the referenced external issue for future updates. Thanks for your report!
Author
Owner

@warpdesign commented on GitHub (Dec 13, 2020):

@DHowett Sad :( Does it mean every app using XAML are having the same problems? Any ETA for WinUI 3?

@warpdesign commented on GitHub (Dec 13, 2020): @DHowett Sad :( Does it mean every app using XAML are having the same problems? Any ETA for WinUI 3?
Author
Owner

@zadjii-msft commented on GitHub (Dec 14, 2020):

Only "XAML Islands" apps (Win32 apps using XAML, not UWP apps) will have this problem. Unfortunately, DHowett and I don't work on the WinUI team, so we don't really comment on the release schedule for WinUI 3 (because we don't know it 😜)

@zadjii-msft commented on GitHub (Dec 14, 2020): Only "XAML Islands" apps (Win32 apps using XAML, not UWP apps) will have this problem. Unfortunately, DHowett and I don't work on the WinUI team, so we don't really comment on the release schedule for WinUI 3 (because we don't know it 😜)
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#11791