[Bug Bash] Quick Fix button being rendered to wrong spot

[carlos-zamora]

Windows Terminal version

1.22.2081.0 (bug bash on 7/30)

Windows build number

No response

Other Software

No response

Steps to reproduce

It's being placed in random positions. However, it'll snap to the cursor if you resize when in that state.

May be similar to this bug:
Opening snippets pane causes prompt to disappear and QF button moved to where the prompt is supposed to be?

Confirmed it's not related to snippets, so there's something weird going on with drawing the QF button.

Expected Behavior

No response

Actual Behavior

x

[carlos-zamora]

Oh no, I did a git bisect (a few, actually) and it led me to:
450eec4 A minor ConPTY refactoring: Goodbye VtEngine Edition (#17510)

[lhecker]

Flushing in the old VtEngine happened with a 16ms delay (unless the content scrolled) so it's not unlikely that we had a bug already but simply didn't notice due to the delayed output from cmd.

Looking at this image:

Doesn't cmd emit the command-not-found VT sequence when printing that exact message? In that case I think it's just natural that the quick-fix button is possibly on the same line. Without knowing the quick-fix code exactly, I suspect we're using a resume_foreground somewhere, lock the text buffer, ask for the cursor position and then show the bulb next to the cursor, right? That can't work reliably since it's timing sensitive and races with the concurrently running cmd output.

If we're fine with showing the bulb next to the cmd error message, the easiest fix for this may be to transmit the row number with the event that informs the control to show the bulb. Unfortunately, we don't yet have unique row IDs that would make it possible to figure out the vertical offset while the text buffer is possibly concurrently scrolling. In that case I think we should add them.