Repository: microsoft/terminal (language: cpp)

Issue:
Output containing OSC sequences (e.g. shell integration) is not rendered (regression)
### Windows Terminal version

432dfcc4902d1a8393217a5f529d07e65182a3f8 and later

### Windows build number

10.0.19045.4291

### Other Software

_No response_

### Steps to reproduce

1. Enable shell integration in oh-my-posh or set your PowerShell prompt to
   ```ps
   function prompt {
       "$([char]0x1b)]133;D`a$([char]0x1b)]133;A`a> $([char]0x1b)]133;B`a"
   }
   ```
2. Open a new pane/window to load the profile
3. (Optionally) Try pressing Ctrl+C and normal characters

### Expected Behavior

_No response_

### Actual Behavior

The prompt (and `^C` sometimes too) is not rendered until a printable character is entered from keyboard or the window is resized (resizing doesn't always help).

https://github.com/microsoft/terminal/assets/12915102/75bff0bb-0ad7-48ec-9209-0718279caec6

https://github.com/microsoft/terminal/assets/12915102/e560387f-2f12-4d9c-870d-af21d053cb08

This regression was introduced in 432dfcc4902d1a8393217a5f529d07e65182a3f8 (#17194)


Discussion / hints:
Hi I'm an AI powered bot that finds similar issues based off the issue title.

Please view the issues below to see if they solve your problem, and if the issue describes your problem please consider closing this one and thumbs upping the other issue to help us prioritize it. Thank you!


### Closed similar issues:
- [[REGR #3956] Terminal incorrectly splits part of escape sequence (#4131)](https://github.com/microsoft/terminal/issues/4131),  similarity score: 0.78
- [OSC sequences in prompt get front loaded (#11220)](https://github.com/microsoft/terminal/issues/11220),  similarity score: 0.75

> Note: You can give me feedback by thumbs upping or thumbs downing this comment.
@j4james ping
I'm very sorry about this. I suspect it might be something else that needs to be reset in `XtermEngine::StartPaint` when returning early. But if it's not obvious, and we need a quick fix, feel free to revert PR #17194. That bug probably affects far fewer people.
Ah yep yeah I can confirm this too. It's... pretty rough, though I honestly don't know how many people have shell integration set up. 

@lhecker you wanna take a look at this, see if we can't come up with a more clever fix than just reverting #17194? If we can't, then I'll probably make the argument that we need to revert that later this week. 
Hmm I wonder if it has to do with the `_cursorMoved` changes. Since it was always `true` this always caused a render pass. Restoring the old `_cursorMoved = true` code does make everything work again.

Fix patch:
diff --git a/src/renderer/vt/XtermEngine.cpp b/src/renderer/vt/XtermEngine.cpp
index 9c489aa29cc..4df161befc1 100644
--- a/src/renderer/vt/XtermEngine.cpp
+++ b/src/renderer/vt/XtermEngine.cpp
@@ -44,6 +44,10 @@ XtermEngine::XtermEngine(_In_ wil::unique_hfile hPipe,
         // have been reset in the EndPaint call. But since that's not going to
         // happen now, we need to reset it here, otherwise we may mistakenly skip
         // the flush on the next frame.
+        if (!_noFlushOnEnd)
+        {
+            _Flush();
+        }
         _noFlushOnEnd = false;
         return hr;
     }


Test patch: