"Test Results" panel aggressively steals focus

[andrewheumann]

Environment

1. vscode-jest version: 6.2.0
2. node -v: v20.9.0
3. npm -v or yarn --version: v10.1.0
4. npm ls jest or npm ls react-scripts (if you haven’t ejected):

   pringle@0.0.0 /Users/andrewheumann/Dev/pringle
   ├─┬ @vue/vue3-jest@29.2.6
   │ └── jest@29.7.0 deduped
   ├── jest@29.7.0
   └─┬ ts-jest@29.1.2
   └── jest@29.7.0 deduped

5. your vscode-jest settings if customized:
   • jest.jestCommandLine? n/a
   • jest.autoRun? n/a
   • anything else that you think might be relevant? n/a
6. Operating system: Mac OS 14.2.1 (23C71)

Prerequisite

• are you able to run jest test from the command line? yes
• how do you run your tests from the command line? (for example: npm run test or node_modules/.bin/jest) npm run test

Steps to Reproduce

Example Repo https://github.com/andrewheumann/jest-steals-focus

In this bare repository, on every file save, "Test Results" steals focus in the VS code panel. I want my terminal to stay front and center.

https://github.com/jest-community/vscode-jest/assets/31935763/fadb9b25-25e5-4e01-bd5d-eac31978b37e

In another repo, it's stealing focus on every git action.

Even if I explicitly close the Test Results panel tab, it re-opens itself on every file save or git action.

[connectdotz]

[updated]

To disable automatic focus shifting to the test-results tab, set "testing.openTesting": "neverOpen".

For a comprehensive understanding of focus behavior, especially why setting jest.outputConfig.revealWithFocus to "none" (the default value) doesn't prevent the test-results tab from stealing focus, refer to jest.outputConfig. Adjusting "testing.openTesting" to "neverOpen" resolves this issue, as detailed in the documentation.

[hugoburguete]

I also noticed this upon updating VSCode to the most recent release.

Option 3 seems to make the most sense to me (from a user perspective). The option of whether to run it automatically or not shouldn't be linked to focusing the test results panel.

But happy with whatever decision the maintainers choose in the end.

[connectdotz]

It looks like I have made the issue more complicated than it is, sorry. I updated my earlier comment and provided a more straightforward answer there instead.

Please let me know if there are any other questions.

[connectdotz]

@v-msft, is setting "testing.openTesting": "neverOpen" not working for you? You could set it in the user-level settings.json, so you don't have to do this for every one of your VSCode workspaces.

Yeah, I know it's annoying. I wish we could make "neverOpen" the default value for "testing.openTesting", especially in auto-run scenarios. Unfortunately, the setting and the test results panel are part of the VSCode core, over which we have little control regarding their implementation. The VSCode team provided "testing.openTesting" precisely to address different focus preferences.

That being said, I think we could consider showing a warning and an option to update the setting if the user consents. Do people think that would help reduce the pain?

[sh-pq]

I confirm that using "testing.openTesting": "neverOpen" resolves this issue for me.

Just this past week after updating VS Code I also noticed this issue: every single time I ran any test (such as on any save) the terminal panel would open and the Testing tab would steal focus. That was new and unpleasant, such that I had to disable the automatic test runner completely.

Using "testing.openTesting": "neverOpen" however just makes the tests run silently in the background which is exactly the behaviour I want.

[connectdotz]

Close this issue as there is a clear configuration solution mentioned above.

[GeorgeWL]

I tried setting it to "testing.openTesting": "openOnTestFailure" and it still opens every time, instead of only on failures

[hugoburguete]

I tried setting it to "testing.openTesting": "openOnTestFailure" and it still opens every time, instead of only on failures

I feel like this is a different bug from the original one. Maybe this should be raised as a different bug to mention that the setting is not working as expected?

[connectdotz]

@GeorgeWL I was able to repo your issue, but I think @hugoburguete is right, this is a different issue, it's actually a real bug. 😓 I will patch it shortly if you want to creat a new issue for it.

[GeorgeWL]

@GeorgeWL I was able to repo your issue, but I think @hugoburguete is right, this is a different issue, it's actually a real bug. 😓 I will patch it shortly if you want to creat a new issue for it.

I've done that now and referenced my earlier comment in that report