Unsupported CSI, OSC or DEC private mode parsing is interrupted on a delay

[egmontkob]

Environment

Windows build number: Win32NT 10.0.18362.0
Windows Terminal version (if applicable): 0.5.2762.0

Steps to reproduce

Sibling issue of #3080. Execute this:

echo -ne '\e[?12'; sleep 1; echo -ne '34h'

Expected behavior

As if the delay wasn't there, this should attempt to enable DEC private mode 1234, which is unsupported by WT (actually undefined), so no action should be taken.

Actual behavior

34h is printed, suggesting that parsing the sequence got interrupted.

Note that if the given number is supported (e.g. 1049 to switch to the alternate screen) then the sequence is parsed and executed correctly even when a delay is injected.

---

Update:

The same goes for unsupported CSI modes too, e.g. \e[22;0;0t (save title on stack) or \e[4l (replace mode).

[DHowett-MSFT]

Oh, this is interesting. We only flush the unknown/unparseable string that completed the sequence! That'll be the root cause for the sibling bug as well.

Thanks!

[DHowett-MSFT]

(We successfully identify that we're dealing with \e[?1234h, but by the time we get the h we've lost the beginning as you've rightly surmised.)

[egmontkob]

Explicit hyperlinks (not yet supported: #204) are also affected in the same way (tested in 0.8.10091.0).

Test with:

cat hyperlink-demo.txt

The longer the target URL, the more likely the corruption occurs, but it is easily reproducible with short URLs too by injecting a delay.

This is likely to cause actual problems, since there's no way to detect (or advertise) hyperlink support, most of the apps just assume that the terminal at least silently ignores the sequence. See e.g. the recent discussion under the hyperlink spec.