Figure out how to handle drag-drop in an elevated session

[DasCleverle]

Environment

Windows build number: 19041
Windows Terminal version: 1.0.1401.0

Steps to reproduce

• Open Windows Terminal
• Open a second tab (the shell does not matter)
• Try to drag any tab

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.

[zadjii-msft]

Are you running the Terminal elevated / as an Administrator?

[DasCleverle]

Yes, that seems to be it.
If I start it elevated on my private PC it also stops working. But on my work PC it seems to run elevated by default (UAC is configured to not show a prompt). Is there a way to disable it? As I'm working nearly exclusively in WSL, I don't really need to have it run as admin.

/edit
I can't enable UAC as some group policy scripts run regedit on startup and I get like 10 prompts when I log in.

[DHowett]

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".

[conioh]

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. :)

[sba923]

Would there be a way to inform the user this is (currently) not supported, some visual clue maybe?

[zadjii-msft]

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

[dracan]

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.

[zadjii-msft]

@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.

Docs link

---

More internal links, for self:

• OWL-side: MSFT:44326151 (specifically elevated drag drop)
  • Also, MSFT:45980126 for the tabbed titlebar WinUI 3 changes that may be relevant
• Terminal-side: MSFT:44326113
• Platform-side: MSFT:35616520

[dracan]

@zadjii-msft - Perfect! I never like reaching for that darn mouse anyway - so hotkeys work perfectly. Thank you very much 🙂🙏

[dracan]

@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!

[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!

@dracan:

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 Microsoft.UI.Xaml etc. (WinUI 3) replace it with Windows.UI.Xaml etc. (UWP). Calling it a "re-write of all of WT" and "a MASSIVE undertaking" is misleading, disingenuous, and incompatible with the project's CoC. I must request you to refrain from doing that.

See https://learn.microsoft.com/en-us/windows/apps/windows-app-sdk/migrate-to-windows-app-sdk/migrate-to-windows-app-sdk-ovw

Just perform the equivalent of the 3 steps Microsoft officially suggests in the reverse direction:

1. Create a new UWP project WinUI 3 packaged desktop project (see Create your first WinUI 3 project). That could go into your existing solution.
2. Copy your XAML/UI code. In many cases you can simply change namespaces (for example, Microsoft.UI.* to Windows.UI.* Windows.UI.* to Microsoft.UI.*).
3. Copy your app logic code. Some APIs need tweaks, such as Popup, Pickers, and SecondaryTiles.

[DHowett]

@conioh Windows Terminal does not currently use WinUI 3 or WinAppSDK. It uses system XAML (built into Windows) plus Microsoft.UI.Xaml (WinUI 2) controls.

Moving the application from System XAML plus WinUI2 to System XAML only¹ 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 Windows.UI.Xaml namespace doesn't have many of the controls which we are using (including the TabView, which is responsible for most of the actual UI 😆).

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

1. moving from whichever parts of Microsoft.UI.Xaml we are using to Windows.UI.Xaml as you recommend ↩