-
Notifications
You must be signed in to change notification settings - Fork 8.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Still cannot drop files to Terminal running as admin #17291
Comments
Hi I'm an AI powered bot that finds similar issues based off the issue title. Please view the issues below to see if they solve your problem, and if the issue describes your problem please consider closing this one and thumbs upping the other issue to help us prioritize it. Thank you! Closed similar issues:
|
Notes: For the tab dragging scenario:
But that's not file drag/drop. That code references all of |
Can you clarify if the issue occurs when UAC is enabled /? For us, when it's enabled, drag & drop into conhost doesn't work. In that situation, it's not expected to work for Terminal either. |
Same with me. i also can't not drop file to window terminal from andy where , Whether the uac or admin is enabled or not |
Windows Terminal version
1.20
Windows build number
10.0.19045.3930
Other Software
Windows File Explorer 10.0.19041.3758
Steps to reproduce
First, ensure you logged in as an ordinary admin account (I've not tested on the built-in Administrator account yet but I guess the problem will remain.)
Method 1: Set EnableLUA=1 (enable UAC), run Terminal with admin permission, drag a file from Desktop and drop it to Terminal.
Method 2: Set EnableLUA=0 (disable UAC), directly run Terminal, and do the drag&drop.
Expected Behavior
I am simply expecting drag & drop can work.
Actual Behavior
A cursor indicating "unavailable" will be displayed through either method above.
Such drag&drop is supported by the legacy conhost but not Windows Terminal. That's weird. Don't tell me this issue is a duplicate of #14946 or #15996 and that you have already fixed this in 1.18. I tested on both 1.18 and 1.20 only to find the problem remaining.
The text was updated successfully, but these errors were encountered: