Repository navigation
"Dart: Dev Tools Browser" should be clearly documented as only working for local workspaces #5431
Description
Describe the bug
Split off from flutter/devtools#8912 (see flutter/devtools#8912 (comment))
If you open devtools in the browser while debugging in Dart in VS Code in WSL, the "Dart: Dev Tools Browser" setting does not seem to take effect. Whether it is set to "chrome" or "default", it always opens in "default", which is Edge on my system. Note that this only is an issue for me in WSL, and the setting works appropriately in Windows natively.
To Reproduce
- Set default browser on your system to Edge (or something else non-Chrome)
- Open VS Code in WSL2 Ubuntu
- Set the "Dart: Dev Tools Browser" setting to "chrome"
- debug a Dart program
- At a breakpoint, open devtools in browser
- Observe that it opens in non-Chrome instead of Chrome
Expected behavior
Setting works, opens in chrome if specified as such.
Screenshots
Please complete the following information:
Workspace Environment
Dart Code extension: 3.106.0
App: Visual Studio Code
App Host: desktop
Remote: wsl
Host Kind: wsl
Version: linux 1.97.2
Workspace type: Dart (LSP)
Workspace name: rohd-hcl [WSL: Ubuntu]
Dart (3.7.0): /usr/lib/dart
Flutter (undefined): undefined (No device)
Output from 'dart info'
/usr/lib/dart/bin/dart info
If providing this information as part of reporting a bug, please review the information
below to ensure it only contains things you're comfortable posting publicly.
General info
- Dart 3.7.0 (stable) (None) on "linux_x64"
- on linux / Linux 5.15.167.4-microsoft-standard-WSL2 Code already includes yaml support, doesn't need providing #1 SMP Tue Nov 5 00:21:55 UTC 2024
- locale is C.UTF-8
Project info
- sdk constraint: '>=3.0.0 <4.0.0'
- dependencies: collection, meta, rohd, rohd_vf
- dev_dependencies: logging, test
Process info
| Memory | CPU | Elapsed time | Command line |
|---|---|---|---|
| 84 MB | 0.3% | 06:16 | dart devtools --machine --allow-embedding --dtd-uri ws:/qYCG49aSQsE= |
| 382 MB | 0.0% | 03:49:38 | dart language-server --protocol=lsp --client-id=VS-Code-Remote --client-version=3.104.0 |
| 431 MB | 0.3% | 02:14:39 | dart language-server --protocol=lsp --client-id=VS-Code-Remote --client-version=3.106.0 |
| 362 MB | 0.2% | 01:37:33 | dart language-server --protocol=lsp --client-id=VS-Code-Remote --client-version=3.106.0 |
| 332 MB | 3.6% | 07:00 | dart language-server --protocol=lsp --client-id=VS-Code-Remote --client-version=3.106.0 |
| 78 MB | 0.0% | 03:49:38 | dart tooling-daemon --machine |
| 79 MB | 0.0% | 01:37:33 | dart tooling-daemon --machine |
| 108 MB | 0.5% | 07:00 | dart tooling-daemon --machine |
Activity
DanTup commentedon Mar 4, 2025
This is actually working as intended - however I see the description on the setting does not mention this.
There are generally two modes in which the VS Code extension can run:
When running "locally" (eg. not WSL), the extension host is the same machine where the VS Code UI is running. We can spawn processes and know that the user will see them. In this code, we support launching Chrome (by delegating to the DevTools server, which finds the process and spawns it).
When running "remotely", the extension host is not running in the same place as the VS Code UI. It might be a remote server/container (for example in the case of Codespaces), but it might also just be some kind of VM like WSL or Docker. In these cases, we cannot be sure that a spawned process would be visible to the user (for example spawning a Chrome process on a backend IDX container would not show up inside the users browser if they're using IDX).
So, when running "remotely", we never delegate to the DevTools server to spawn Chrome, and instead we always ask the host/IDE to spawn a browser instead (which will use the system default).
WSL is a little odd in that I think you can spawn Windows processes from within it. However, this is a detail that I don't believe is expressed by the VS Code API (nor do I think the DevTools server would successfully locate a Windows install of Chrome from inside a WSL container), so I think for now we're restricted to this behaviour.
I'll update the text on the setting to make this clear. I'm also curious why you'd trying to use Chrome specifically here - the reason we originally supported this was just because DevTools/Flutter web didn't work great in other browsers. Since Edge is based on Chromium, I would've expected this to be a non-issue today, and the need to use Chrome specifically is reduced.
Tweak text for devToolsBrowser setting
mkorbel1 commentedon Mar 4, 2025
Thanks, your updated description I think will help clarify here! This makes sense to me.
I never looked at this option at all until I was trying to reproduce this issue: flutter/devtools#8982. I've had no problem just using Edge, generally.
DanTup commentedon Mar 5, 2025
Thanks, then I'll close this as updating the description being the fix. If you do notice any issues in Edge, then probably it's worth filing them specifically (probably in the DevTools repo, although it's also possible they'd be Flutter or Dart SDK issues).
[-]"Dart: Dev Tools Browser" setting is not respected in WSL[/-][+]"Dart: Dev Tools Browser" should be clearly documented as only working for local workspaces[/+]