<h1 dir="auto">Environment</h1>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="Windows build number: Win32NT 10.0.18362.0
Windows Terminal version (if applicable): 0.5.2762.0"><pre lang="none" class="notranslate"><code class="notranslate">Windows build number: Win32NT 10.0.18362.0
Windows Terminal version (if applicable): 0.5.2762.0
</code></pre></div>
<h1 dir="auto">Steps to reproduce</h1>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="echo -ne '\e]10;foo\e'; sleep 1; echo -ne '\\'; sleep 5; echo; sleep 1; echo; sleep 10"><pre class="notranslate"><code class="notranslate">echo -ne '\e]10;foo\e'; sleep 1; echo -ne '\\'; sleep 5; echo; sleep 1; echo; sleep 10
</code></pre></div>
<h1 dir="auto">Expected behavior</h1>
<p dir="auto">Two linefeeds eventually, nothing more.</p>
<p dir="auto">OSC 10 sets the default foreground, it's not yet supported by WT. You can replace it with any other number that's not yet supported.</p>
<p dir="auto">The terminating sequence of <code class="notranslate">OSC</code> should be <code class="notranslate">ST</code> accoding to the standard (<code class="notranslate">BEL</code> is a commonly used but nonstandard choice instead). <code class="notranslate">ST</code> in the <code class="notranslate">C0</code> set is <code class="notranslate">ESC</code> followed by <code class="notranslate">\</code>.</p>
<p dir="auto">Now we insert a bit of delay in the middle of <code class="notranslate">ST</code>. Such difference in timing should never make a difference in the final outcome, not even when the sequence is unsupported.</p>
<h1 dir="auto">Actual behavior</h1>
<p dir="auto">The following weirdnesses occur:</p>
<ul dir="auto">
<li>
<p dir="auto">A literal <code class="notranslate">\</code> gets printed. It shouldn't.</p>
</li>
<li>
<p dir="auto">That <code class="notranslate">\</code> gets printed 6 seconds after starting the command line, rather than 1 second after. That is, not immediately when received, but when the next character (whether that's a newline or not) is received.</p>
</li>
<li>
<p dir="auto">Subsequent newlines don't move the cursor to the beginning of the line as expected, but walk downwards in the second column.</p>
</li>
</ul>
<p dir="auto">So it seems the parser might be stuck in some weird mode??</p>
<p dir="auto">The bug does not occur if the delay is eliminated and the unsupported escape sequence is printed in a single step. It is completely ignored then, as expected.</p>
<p dir="auto">The bug does not occur with supported escape sequences either, such as setting the title with OSC 0. It's immune to injected delays, as expected.</p>
<ul dir="auto">
<li>
<p dir="auto">Your Windows build number:  (Type <code class="notranslate">ver</code> at a Windows Command Prompt)<br>
10.0.18362.113</p>
</li>
<li>
<p dir="auto">What you're doing and what's happening: (Copy &amp; paste specific commands and their output, or include screenshots)<br>
I am using the Czech keyboard. We write some characters like <code class="notranslate">|</code> by pressing <code class="notranslate">RightAlt-W</code>. There are more characters like that, all are accessible using Right Alt.</p>
</li>
<li>
<p dir="auto">What's wrong / what should be happening instead:<br>
When I press the shortcut, no character is written in the output.</p>
</li>
</ul>