-
Notifications
You must be signed in to change notification settings - Fork 8.4k
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
Figure out how to handle drag-drop in an elevated session #6661
Comments
Are you running the Terminal elevated / as an Administrator? |
Yes, that seems to be it. /edit |
So, okay, here's a weird thing. We are working around a crash (!) caused by the drag/drop host being at a different integrity level than the Terminal application. I know, that sounds silly. I agree. Now, the problem here is that since your entire user session has UAC disabled, there is no integrity level separation. Drag/drop would work perfectly fine for you! Unfortunately, we have no way of knowing that. All we can check is "does this user have admin rights?" without really violating the bounds of our contract with the system. I'm going to make this bug the master for "figure out a good story for drag/drop during elevation". |
Could you elaborate on this? Is it related to your use of XAML islands? I remember earlier preview versions crashing immediately when I tried to drag admin tabs. Not crashing is better than crashing, but being able to drag them would be even better. :) |
Would there be a way to inform the user this is (currently) not supported, some visual clue maybe? |
I'm pretty sure when you try to drag/drop into an elevated Terminal window, the OS automatically replaces the drag/drop visual with the 🚫 icon to indicate that this isn't supported |
Just wondering if there's been any further development with this? I find the ability to reorder tabs extremely useful, and I quite often have my WT run as admin. It's quite frustrating not being able to reorder just because I'm in an elevated prompt. |
@dracan Heyo sorry, missed this while I was on leave and only just finding this comment now. No, unfortunately, there hasn't been any progress on drag/drop in elevated windows. Alas, that's not something we have a lot of power over. (Note to self, this is tracked in MSFT:35616520) Now, on the bright side, there is a workaround for moving tabs without using drag/drop. There's a pair of actions in the Command Palette for "Move tab forward" / "Move tab backward" which will reorder your tabs without the need to invoke the drag/drop service. That might be a possible workaround. More internal links, for self:
|
@zadjii-msft - Perfect! I never like reaching for that darn mouse anyway - so hotkeys work perfectly. Thank you very much 🙂🙏 |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
@conioh - Sounds like you're suggesting a codebase re-write of all of WT to use a different platform just to fix this small issue of tab drag-and-drop when running as admin? That sounds like a MASSIVE undertaking to me just to fix this one thing! |
Only to someone who's not really listening. Actually it sounds like I'm suggesting a search-and-replace of just a tiny edge of Windows Terminal - wherever it says Just perform the equivalent of the 3 steps Microsoft officially suggests in the reverse direction:
|
@conioh Windows Terminal does not currently use WinUI 3 or WinAppSDK. It uses system XAML (built into Windows) plus Moving the application from System XAML plus WinUI2 to System XAML only1 and packaging it as a "UWP" application (which runs at an integrity level that is inappropriate for the basic system management tasks Terminal is used to run (which is important because Terminal needs to spawn processes, which would be sandbox-restricted)) would present a significant regression in usability, deployment and project direction. In addition, it is not a simple search and replace--especially given that the We're just not going to do that, because on top of being a significant undertaking it will send us back to the halcyon days of 2016. Going the other direction: Moving the application from System XAML plus WinUI 2 to WinUI 3 where the drag-drop issue is expected to be fixed is also a significant undertaking. Anyway, this discussion is not going anywhere. I'm going to lock it for a while. Footnotes
|
Environment
Steps to reproduce
Expected behavior
Tabs are attached to the mouse cursor and can be dragged to the desired location.
Actual behavior
Nothing happens
I can only reproduce this issue on my work PC. My private PC works just fine. They use the exact same settings file. Also restarting the computer or reinstalling WT does not help.
The text was updated successfully, but these errors were encountered: