Output Panel - Add Option to Prevent Stealing Focus

[jstm88]

Output Panel Mass Spam - A Workflow Disruption

While using VS Code, the "Output" panel appears for many different reasons. It is highly disruptive since it takes over the panel which was currently being used. This is one of the very few times where VS Code forcibly reconfigures the user's window setup with no way to prevent it.

It's been long understood that this is primarily caused by various extensions. They are supposed to only trigger the output window when the message is actually important. However, they often make poor choices about what is, in fact, important, resulting in a mass spam of output messages.

The Flawed Argument

Previous issues have been closed by pretending that this is "just the extension's fault" and that "we aren't responsible for what the extensions do".

While this may be technically true, we need to realize that it is going to be effectively impossible to fix in every extension. That ship has sailed, and this will be a problem that never goes away unless VS Code begins actually enforcing rules about how it can be used, and I don't think that's a viable solution anyway.

The Solution

Add a toggle to prevent the Output panel from taking focus.

This would change nothing for existing users, while giving advanced users who have been dealing with this madness a way to instantly solve it. Note that this does not disable or remove the Output panel - it simply disables its ability to steal focus from the panel which is currently displayed. Messages would still be available for manual review, and badging the tab would be a way to have the user notified without interrupting.

Additionally, this solution could be further refined by allowing the user to decide which extensions can focus (and/or badge) the Output panel. In my view, this is the ideal form of this feature, allowing the user to decide which extensions are important and which need to be "muted".

Links

Other issues have brought this up before, going all the way back to August 2017.

#143657
#33262
#105270
#112345
#143657
#161257
#163840

Conclusion

It's very clear that this is not something that's going to ever go away, and it's time to stop with the inexplicable refusal to do anything about it simply because "it's technically the extension's fault".

We need to stop pretending the problem doesn't exist, especially when the solution is so simple and obvious.

[sandy081]

/duplicate

#105270

[vscodenpa]

Thanks for creating this issue! We figured it's covering the same as another one we already have. Thus, we closed this one as a duplicate. You can search for similar existing issues. See also our issue reporting guidelines.

Happy Coding!

[jstm88]

/duplicate

#105270

Please, can you actually read the ticket?

I address why this should not be closed - the others were all closed prematurely for only the reason that they were "duplicates" despite the fact that the original (which is being used as "justification" to close the others) was closed in error. The problem was not understood and now we have a chain of "closed as duplicate" tickets haunting us and blocking this problem from being addressed.

[jstm88]

@sandy081 @sbatten Repeating the request to reopen one of the tickets on this long-standing issue.

It doesn't matter which one - just one of them needs to be reopened. We keep opening new tickets because the problem has not yet been solved, so by keeping one open the issue can actually be tracked and addressed.

[jstm88]

@sandy081 The issue is not going to go away by ignoring it. Please reopen one of these tickets.

[jstm88]

Officially, I think #105270 should be reopened since it is where most of the discussion is happening.

@sandy081 You know we're going to keep pinging you until one of these tickets is reopened. The users have spoken repeatedly and the problem is not going away until it's fixed.

[calumgrant]

What we need is for someone to write a VScode extension that deliberately hangs the language server, writes to the output window, and pops up messages spuriously. Because this is how real-world extensions actually behave. It's the job of VScode to be robust against these kinds of problem.