starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-04 05:35:20 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

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

New Issue
Open
opened 2026-01-31 01:49:33 +00:00 by claunia · 15 comments
claunia commented 2026-01-31 01:49:33 +00:00
Owner
Copy Link

Originally created by @DasCleverle on GitHub (Jun 24, 2020).

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

Originally created by @DasCleverle on GitHub (Jun 24, 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: 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 ![EPSXa3QONG](https://user-images.githubusercontent.com/6125226/85620898-b6517d00-b664-11ea-9dff-cc5391969e26.gif) 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.
claunia commented 2026-01-31 01:49:35 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jun 24, 2020):

Are you running the Terminal elevated / as an Administrator?

@zadjii-msft commented on GitHub (Jun 24, 2020): Are you running the Terminal elevated / as an Administrator?
claunia commented 2026-01-31 01:49:35 +00:00
Author
Owner
Copy Link

@DasCleverle commented on GitHub (Jun 24, 2020):

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.

@DasCleverle commented on GitHub (Jun 24, 2020): 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.
claunia commented 2026-01-31 01:49:36 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jun 26, 2020):

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

@DHowett commented on GitHub (Jun 26, 2020): 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".
claunia commented 2026-01-31 01:49:36 +00:00
Author
Owner
Copy Link

@conioh commented on GitHub (Oct 3, 2020):

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

@conioh commented on GitHub (Oct 3, 2020): > 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. :)
claunia commented 2026-01-31 01:49:36 +00:00
Author
Owner
Copy Link

@sba923 commented on GitHub (Mar 4, 2022):

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

@sba923 commented on GitHub (Mar 4, 2022): Would there be a way to inform the user this is (currently) not supported, some visual clue maybe?
claunia commented 2026-01-31 01:49:36 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Mar 7, 2022):

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

@zadjii-msft commented on GitHub (Mar 7, 2022): 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
claunia commented 2026-01-31 01:49:37 +00:00
Author
Owner
Copy Link

@dracan commented on GitHub (Sep 15, 2022):

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 commented on GitHub (Sep 15, 2022): 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.
claunia commented 2026-01-31 01:49:37 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jan 16, 2023):

@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
@zadjii-msft commented on GitHub (Jan 16, 2023): @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](https://learn.microsoft.com/en-us/windows/terminal/customize-settings/actions#move-tab) --- 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
claunia commented 2026-01-31 01:49:37 +00:00
Author
Owner
Copy Link

@dracan commented on GitHub (Jan 16, 2023):

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

@dracan commented on GitHub (Jan 16, 2023): @zadjii-msft - Perfect! I never like reaching for that darn mouse anyway - so hotkeys work perfectly. Thank you very much 🙂🙏
claunia commented 2026-01-31 01:49:38 +00:00
Author
Owner
Copy Link

@conioh commented on GitHub (Jan 17, 2023):

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.

@conioh commented on GitHub (Jan 17, 2023): > 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](https://learn.microsoft.com/en-us/windows/terminal/customize-settings/actions#move-tab) @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](https://task.ms/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.
claunia commented 2026-01-31 01:49:38 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jan 17, 2023):

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.

@zadjii-msft commented on GitHub (Jan 17, 2023): 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](https://github.com/microsoft/WindowsAppSDK/issues). (_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.
claunia commented 2026-01-31 01:49:38 +00:00
Author
Owner
Copy Link

@conioh commented on GitHub (Jan 17, 2023):

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?

@conioh commented on GitHub (Jan 17, 2023): > 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](https://github.com/microsoft/WindowsAppSDK/issues). 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?
claunia commented 2026-01-31 01:49:38 +00:00
Author
Owner
Copy Link

@dracan commented on GitHub (Jan 18, 2023):

@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 commented on GitHub (Jan 18, 2023): @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!
claunia commented 2026-01-31 01:49:38 +00:00
Author
Owner
Copy Link

@conioh commented on GitHub (Nov 7, 2023):

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.
@conioh commented on GitHub (Nov 7, 2023): > 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](../../winui/winui3/create-your-first-winui3-app.md))~. 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**, **Picker**s, and **SecondaryTile**s.
claunia commented 2026-01-31 01:49:39 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Nov 7, 2023):

@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 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 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 ↩︎

@DHowett commented on GitHub (Nov 7, 2023): @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
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Area-UserInterface External-Blocked-WinUI3 Help Wanted Issue-Bug Issue-Task Priority-2 Product-Terminal
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#9244
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?