search

microsoft / terminal

The new Windows Terminal and the original Windows console host, all in the same place!
MIT License
95.56k stars 8.32k forks source link

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

Open DasCleverle opened 4 years ago

DasCleverle commented 4 years ago

Environment

Windows build number: 19041
Windows Terminal version: 1.0.1401.0

Steps to reproduce

Expected behavior

Tabs are attached to the mouse cursor and can be dragged to the desired location.

Actual behavior

Nothing happens EPSXa3QONG

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 commented 4 years ago

Are you running the Terminal elevated / as an Administrator?

DasCleverle commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 2 years ago

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

zadjii-msft commented 2 years ago

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 commented 2 years ago

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 commented 1 year ago

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

dracan commented 1 year ago

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

conioh commented 1 year ago

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

@zadjii-msft, thanks. This is useful.

However one must still wonder how Microsoft's leading, native, non-deprecated UI toolkit doesn't support drag and drop in 2023, almost 40 years after the first release of Windows.

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)

I understand that the Windows Terminal team is not responsible for the inadequacies of the team responsible for WinUI. Fixing WinUI itself is indeed "not something [you] have a lot of power over". But there is something over which you hold all the power and can't blame anyone else - the decision to use WinUI.

I have lots of programs on my computer, and every one of them but Windows Terminal that supports drag and drop supports it also while elevated. This includes both application using Windows only UI toolkits and cross-platform UI toolkits, such as IDA and Wireshark.

It seems extremely unreasonable that Microsoft produces software that run only on Windows, Microsoft's own operating system, and it doesn't support a basic if not trivial feature of Windows since the days of 1.0, while virtually every other application that runs on Windows, including applications that aren't designed specifically for Windows, do support it.

zadjii-msft commented 1 year ago

Boy there's a lot to unpack here, and frankly, the Terminal repo isn't the place for this discussion. It definitely impacts us, yea, but at the end of the day we're subjects of the platform the same as any other 3p application.

A better place to have that discussion might be the Windows App SDK repo. (It's my understanding that) Fundamentally, the modern drag/drop service was not designed to work with elevated processes. However, through the organic growth of the platform over the years, applications that require elevated processes which leverage the modern platform are now more common, and something the platform needs to do some work to close the gaps.

We're going to continue trying to use the cutting edge of the platform, if only to provide a high-impact surface with which we can identify shortcomings of the platform and push for improvements for the rest of the ecosystem.

I'd recommend continuing the discussion on the WASDK repo (which is basically the repo for the Windows platform). I'm gonna liberally mark comments as off-topic here, so we can focus on workarounds the Terminal might be able to leverage.

conioh commented 1 year ago

Boy there's a lot to unpack here, and frankly, the Terminal repo isn't the place for this discussion. It definitely impacts us, yea, but at the end of the day we're subjects of the platform the same as any other 3p application.

A better place to have that discussion might be the Windows App SDK repo.

I don't understand how the WASDK repo is the place to discuss Windows Terminal's decision to use WinUI/WASDK. OK, WASDK is all kinds of broken. Why subject Windows Terminal to that?

(It's my understanding that) Fundamentally, the modern drag/drop service was not designed to work with elevated processes. However, through the organic growth of the platform over the years, applications that require elevated processes which leverage the modern platform are now more common, and something the platform needs to do some work to close the gaps.

That may be true but that's exactly the part that is irrelevant to this repository. That's WASDK's problem. Irrelevant here.

We're going to continue trying to use the cutting edge of the platform, if only to provide a high-impact surface with which we can identify shortcomings of the platform and push for improvements for the rest of the ecosystem.

How can you honestly say "cutting edge" and "doesn't support drag and drop" simultaneously?

I'd recommend continuing the discussion on the WASDK repo (which is basically the repo for the Windows platform).

I don't understand how the WASDK repo is the place to discuss Windows Terminal's decision to use WinUI/WASDK. OK, WASDK is all kinds of broken. Why subject Windows Terminal to that?

I'm gonna liberally mark comments as off-topic here, so we can focus on workarounds the Terminal might be able to leverage.

I am proposing a workaround for Windows Terminal: Use anything but WASDK/WinUI. Even UWP XAML apps support drag and drop when elevated. Why not use that?

dracan commented 1 year ago

@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 commented 12 months ago

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 commented 12 months ago

@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[^1] 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.

[^1]: moving from whichever parts of Microsoft.UI.Xaml we are using to Windows.UI.Xaml as you recommend