Open nohwnd opened 2 months ago
I tried few approaches to remedy this, without locking output:
Move cursor to start of line when I am done rendering the progress, this allows user to overwrite the progress, and so we don't delete their progress, but it leaves a mess on the screen, especially the timestamp that is rendered all the way to the right, because emitting new-line will not automatically clear the rest of the line.
Move the progress bar all the way down to the terminal (not emitting new line after it). This will cause the user output to start at the end of the line (after the timestamp), which makes the output appear more broken.
Keep it as is with new-line after progress, and clearing of progress. This is probably the best right now, because if there is additional output it at least starts on its own line.
Describe the bug
When the initial implementation of https://github.com/microsoft/testfx/pull/3292 is merged, when there is test output, it can cause the progress bar remain on the screen, because we did not delete it when writing output.
This can also happen when test controller writes to console, because we need to write "delete progress" before any line is output.
In process we can "block" user console writes to synchronize this. But with 2 processes we could only move to the "parent" process, which is not following the current architecture.
In this output the progress should not remain on screen, but we are seeing output from 2 different processes, the testhost writing the progress, and the testhost controller writing the Slowest 10 tests.
When the Slowest 10 tests text reaches the screen, we do not issue ansi codes for "clear progress" (go up one line and delete line), because we cannot be aware of it (it comes from a different process). Console writes it, and then we emit clear progress, because the process still thinks the progress bar is the last line, which deletes 1 line of the testhost controller output (there are only 9 lines for slowest tests visible).
Unless we block all the output, or fully sync the output from the 2 processes we cannot avoid this. This is a problem common to other implementations as well, e.g. here the modern progress bar in Powershell, where we can see the same problem by writing to the console from a different thread while progress is reported:
We can mitigate this problem in process by wrapping the standard Console.Out with a TextWriter that calls the clear progress callback before user outputs to screen.
Steps To Reproduce
Have a test or test controller that writes to screen while there is progress bar.