Change:
await timeout(0); const instance = this.activeInstance; if (instance) { <ins> // HACK: Ensure the panel is still visible at this point as there may have been // a request since it was opened to show a different panel if (pane && !pane.isVisible()) { await this._viewsService.openView(TERMINAL_VIEW_ID, focus); } </ins> await instance.focusWhenReady(true); // HACK: as a workaround for https://github.com/microsoft/vscode/issues/134692, // this will trigger a forced refresh of the viewport to sync the viewport and scroll bar.

Discussion:
Here is my code snippet Trying to run this creates:
I can't seem to reproduce this on code-web or
I was using The only changes were these in
I can still reproduce this in my code. I ran out of source to see what might cause the problem and here is a detailed stack trace: Might be some timing issue
More digging. Here are my findings: I do open the terminal from a debug adapter which brings the debugger viewlet to front right after I created the terminal if I wrap my code into a everything works fine
any tip or fix for this. I improved the performance on my end and a 2 sec delay is now very bad. My Python execution in the Web is now < 500 ms.
I need to reopen this. I tested it on todays insider and I still get
Build I used is: <img width="500" alt="image" src="https://user-"
I will compile steps today on how to reproduce this.
Steps to reproduce: clone cd vscode-python-web-wasm git co dbaeumer/noTimeout npm install npm run compile npm run esbuild open VS Code run as a task or in the terminal run as a task or in the terminal click on the link in the tunnel terminal and press continue open a browser on Run command Use the link from the tunnel open developer tools open in the browser window From the play menu in the editor run Observe: you get the above exception and the terminal is not showing the output Run the action again Observe: the terminal reveals correctly and shows the output
Can reproduce with those steps, the only thing missing was enabling workspace trust and reloading after installing the web extension
Debugging this section: It's visible before so it doesn't do the extra open view, and not visible after it because the debug console steals the opened view.
Even if this issue was fixed such that did not throw (eg. make an optionally synchronous version of or just try ), it would still set visible and then immediately show the debug console. So if you wanted to show the terminal, you would need to call it after the debug console shows (eg. via timeout as you have). I don't think this is an issue that needs to be fixed in the terminal, but rather you should either prevent whatever is showing the debug console as it happens some time after the terminal is created, or move the call to after the debug console shows.

let me know if you disagree.
IMO there are two different things: the fact that the terminal is not in front because the debug terminal comes to front. I do agree that this is something I should address the fact that the terminal seems broken (e.g. it doesn't render the output for the first created terminal). This I agrue is a bug in the terminal. IMO the terminal should function correctly after a create even if I don't call show. So if a user later on clicks on the terminal the output is shown correctly.
the second issue should be fixed by , it won't fix your problem though
to understand it correctly. This will ensure that the terminal is functional after . I can then ensure that I bring the terminal to front () after the debugger is initialized.
yeah, removing that await should ensure the view is visible so the element will be there to attach which means no exception that ruins the state.