Repository: microsoft/terminal (language: cpp)

Issue:
Moving tabs out of terminal doesn't work properly with startupActions
### Windows Terminal version

1.18.2681.0

### Windows build number

10.0.19045.3448

### Other Software

_No response_

### Steps to reproduce

1. Set `startupActions` in the Terminal's configuration (you can set config to the below JSON, it seems that the terminal will auto-generate the rest after and it's still reproducible):
```json
{
    "startupActions": "new-tab -p \"PowerShell\" ; new-tab -p \"Command Prompt\""
}
```
2. Start a terminal.
3. In the PowerShell tab, run some command to get some output (I use this to show whether it's still the same tab after dragging out)
4. Try dragging out the PowerShell tab.
5. Notice the wrong behaviour

### Expected Behavior

I expected the new window to contain the dragged-out tab, without `startupActions` being ran.

### Actual Behavior

The new window does not contain the dragged-out tab and is started as it was the first terminal window per the `startupActions`. The old window no longer has the dragged-out tab either.

https://github.com/microsoft/terminal/assets/6032823/64705355-6d95-44c6-9ea5-32c0fe54025d




Discussion / hints:
Do I understand correctly that the blocking severity applies only to the 1.20 release, not 1.18 or 1.19? 
I'm just kind of trying to determine whether I'll have to figure out a workaround for this (maybe just a shell alias that opens all the terminal windows instead of using startup actions) or if there's any chance I can reasonably wait it out and see it resolved sooner since I have already managed to accidentally kill a shell with some long-running process in it by holding the mouse button for a bit too long and dragging the tab out 😄 
Oh, nah, we're planning on fixing this asap. We're experimenting with some new ways of tracking "blocking" and servicing bugs, since our old method wasn't working great. Alas, that board is private right now (because I don't want folks exposed to the WIP nature of it). 

Needless to say, this is on the radar for a 1.18 servicing release (probably not the first one, but soon<sup>TM
Notes:

* `TerminalWindow::Create` doesn't check `_initialContentArgs` near the top. It just does: https://github.com/microsoft/terminal/blob/1669036e595bcc8a100e7b8b679dc8f4748f2eb7/src/cascadia/TerminalApp/TerminalWindow.cpp#L207-L210. I bet that will blow away the content args with the `startupActions`, even if it shouldn't. 

Fix patch:
diff --git a/src/cascadia/TerminalApp/TerminalWindow.cpp b/src/cascadia/TerminalApp/TerminalWindow.cpp
index e6414406aaa..8be6872e98b 100644
--- a/src/cascadia/TerminalApp/TerminalWindow.cpp
+++ b/src/cascadia/TerminalApp/TerminalWindow.cpp
@@ -204,7 +204,12 @@ namespace winrt::TerminalApp::implementation
         // Pay attention, that even if some command line arguments were parsed (like launch mode),
         // we will not use the startup actions from settings.
         // While this simplifies the logic, we might want to reconsider this behavior in the future.
-        if (!_hasCommandLineArguments && _gotSettingsStartupActions)
+        //
+        // Obviously, don't use the `startupActions` from the settings in the
+        // case of a tear-out / reattach. GH#16050
+        if (!_hasCommandLineArguments &&
+            _initialContentArgs.empty() &&
+            _gotSettingsStartupActions)
         {
             _root->SetStartupActions(_settingsStartupArgs);
         }


Test patch: