Paste is annoyingly asynchronous wrt typeahead

[KalleOlaviNiemitalo]

Windows Terminal version

1.17.1023

Windows build number

10.0.19045.2846

Other Software

git version 2.40.0.windows.1

Steps to reproduce

Run Git Bash in Windows Terminal, while other processes are causing CPU and paging load.

Copy some text to the Clipboard from another application. (For example, copy a Git commit ID.)

In Git Bash, type some characters, press Shift+Insert to paste, and type more characters. (For example, type git cherry-pick initially, and press Enter at the end.)

Expected Behavior

Pasted text should appear in the correct place between the first and second sequence of characters.

Actual Behavior

Pasted text occasionally appears after the second sequence of characters. As if Shift+Insert starts an asynchronous paste operation that completes at some later time and injects its result into the terminal input at that time.

[KalleOlaviNiemitalo]

I think Windows Terminal should postpone the subsequent keyboard input events until the paste operation finishes. This should apply only to those events that become input to the session. It should not apply to events that the Terminal itself handles, like switching tabs or searching. Nor should it apply to reports that Terminal generates in response to requests from the session, rather than from user input.

If the clipboard owner hangs the paste operation altogether, then Windows Terminal could detect that after a timeout and display an information bar that lets the user cancel the paste by clicking an abort button or by pressing Ctrl+Break. If the user cancels the paste, Terminal should also discard all the postponed input of that session, to prevent it from running commands that don't include all the text originally intended by the user. (Not sure how this should behave if broadcast input mode #2634 has been started or stopped during the paste operation.)

[PankajBhojwani]

Thanks for filing this issue! Yes, this is definitely a bug. This behaviour might have improved from PR #15328 (probably not completely fixed though... so we'll leave this issue open)

[KalleOlaviNiemitalo]

The "In-PR" label should be removed because #15360 no longer fixes this according to #15360 (comment).

[zadjii-msft]

Maybe this got better in 1.19/?

[KalleOlaviNiemitalo]

I haven't seen the symptom in 1.19 yet, but TerminalPage::_PasteFromClipboardHandler still does co_await winrt::resume_background(); before it uses the clipboard API and then calls eventArgs.HandleClipboardData(std::move(text)) on the background thread, so I don't believe #15360 can have fixed this completely.