A follow-up to #1256 and #5000. Now that those are in the final stages, it has become more obvious where the papercuts lie.

We CANNOT fix it

• You cannot drag / drop tabs as admin.
  • See Figure out how to handle drag-drop in an elevated session #6661
• When tearing-out with touch, the tab will appear where the pointer is. NOT where the touch is.
  • I'm told there's no way to get the touch position at the end of the drag.

"Tear out v1" gaps

Things that are obvious gaps in the initial version of drag/drop. Firefox-like (hopefully).

• Tabs have no preview of what's being dragged
• Tabs can only be dropped on the TabView, but not the whole titlebar
• The tab item corners are rounded on top, and flat on the bottom
• Dragging a tab off in space shows the red circle (not allowed) icon #15438
  • The tab view item shows a 🚫 when dragging over not the Terminal, even though you totally can just drop there to make a new window
  • There is a way in the Sept'23 OS release to suppress the drag icon, however, this ENTIRELY suppresses the drag icon. That means there's no Move ↗ for successful ones, either. So that's ridiculous.
• VsCode shows that it can accept a "Move" of a Terminal tab, even though that's obviously insane
• The tab view of the target doesn't expand to make room for the new tab. It makes a gap, but it doesn't increase its width, so the existing tabs are clipped on the right
• The target doesn't show a preview of the dragged tab's content "in place" when hovering over the tab view
• We shouldn't "animate in" tab items when dropping. They should just appear
  • It wasn't trivial to just AllowDependentAnimations(false) then re-enable. Presumably they're independent animations
• pressing escape should stop the drag and put the window back where it started
• while tab dragging, if you drag over another window (and switch to 'move' in the image being dragged), the window you've dragged over should be raised in zorder. this could expose places to drop the tab.
• if window is snapped and you drag a tab out, you're using the snap rect (so, left snap and drag out would be as tall as the monitor). You should use the normal position, GetWindowPlacement
• Dragging a Tab across a DPI doesn't re-scale the tab item during the drag microsoft-ui-xaml#8442

The fullness of time gaps

Given infinite engineering resources, what would we like the experience to be? Basically, Chromium-like or better.

Note that this experience is currently blocked entirely for Terminal. We'll need to be able to switch to WinUI 3 (WASDK 1.6) before we can use the new tab APIs they provided

• [megathread] Chromium parity for tab drag/drop #16129
  • Including, but not limited to:
  • Tabs should make a new window as soon as their torn out
  • Torn-out tabs need to be able to snap to snap positions (maximized, snap layouts) without dropping first
  • Multiple tabs can't be dragged/dropped all at once
  • Dragging a tab in a window with a single tab should just drag the window

Resources

Notes to myself on internal threads to investigate

• MSFT:42334223: TabView Crash when moving tab in dozens of tabs
• os.2020!8180615: Suppressing drag feedback icon while dragging a tab