You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Improve UX when features aren't supported in the current run-mode #4050
It's not clear what DevTools the user is allowed to open and when. For example, if a user is running in profile mode and tries to run the "Open Widget Inspector" command in VSCode they are shown this screen:
It seems like that most things are supported in Debug and Profile mode, but show inconsistent messages:
Debug
Profile
Release
Widget Inspector
🟢
🔴
🔴
CPU Profiler
🔴
🟢
🔴
Memory Page
🟡
🟢
🔴
Performance Page
🔴
🟢
🔴
Network Page
🟢
🟢
🔴
Logging Page
🟢
🟢
🔴
For example, when running in debug mode, the toast messages for the CPU Profiler, Memory, and Performances pages are inconsistent. The memory page displays a warning but the CPU Profiler and Performance pages display an error:
If you try to open a DevTools panel in release mode, you get a warning like this, but I'm also wondering if we could clarify this message:
changed the title [-]Improve message when a panel is not supported by the current run-mode[/-][+]Improve UX when features aren't supported in the current run-mode[/+]on Apr 27, 2022
If you try to open a DevTools panel in release mode, you get a warning like this, but I'm also wondering if we could clarify this message:
This debug session is not ready yet or does not support DevTools.
Were you running on the web when you got this message? This message shows up when there's no VM Service URI. This usually means the session is still starting, but I believe for Release builds on web we'll never get one. We can tweak this text to be a bit more specific, although I've tried not to encode too many assumptions about the specific behaviour into VS Code where things might change in Flutter. This is also why some commands might still show up in VS Code, but then it turns out that page is not available (VS Code doesn't really know for certain whether you're running on web, for example - it would have to make assumptions about devices based on their IDs/names, including reading any custom args in your launch config).
Perhaps it would be useful to have an API (for ex. via the DevTools server?) that would allow editors to query the capabilities for DevTools for a given session? Eg., given this VM Service URI, which DevTools pages will be available?
Ah, gotcha. I guess it makes sense we also don't have VM Service URIs for Desktop release builds.
Right now there's not an easy way for VS Code to know whether it doesn't have a VM Service URL because the debug session has not finished starting up, or it's a release build. I think we should be able to get this though (I can see the flutter tool does emit an app.started event in the case of a release build). I've filed Dart-Code/Dart-Code#3945 to do this and improve that specific message which covers the case where DevTools won't be usable at all. I think it makes sense for the other cases - where we can spawn DevTools but that screen is not available for the current app - in DevTools by tweaking the message shown in the original screenshot at the top.
DevTools unified its debug-mode warning banners across screens via DebugModePerformanceMessage, and IDE integrations updated their messaging to clearly indicate when features are unavailable for the current run mode.
If there is more work to do here, please let us know by filing a new issue with up to date information. Thanks!
Activity
[-]Improve message when a panel is not supported by the current run-mode[/-][+]Improve UX when features aren't supported in the current run-mode[/+]DanTup commentedon Apr 28, 2022
Were you running on the web when you got this message? This message shows up when there's no VM Service URI. This usually means the session is still starting, but I believe for Release builds on web we'll never get one. We can tweak this text to be a bit more specific, although I've tried not to encode too many assumptions about the specific behaviour into VS Code where things might change in Flutter. This is also why some commands might still show up in VS Code, but then it turns out that page is not available (VS Code doesn't really know for certain whether you're running on web, for example - it would have to make assumptions about devices based on their IDs/names, including reading any custom
argsin your launch config).Perhaps it would be useful to have an API (for ex. via the DevTools server?) that would allow editors to query the capabilities for DevTools for a given session? Eg., given this VM Service URI, which DevTools pages will be available?
johnpryan commentedon Apr 28, 2022
No, I was running on desktop. I think the widget inspector is unsupported in profile mode, so there's nothing for this panel to do.
DanTup commentedon Apr 28, 2022
Ah, gotcha. I guess it makes sense we also don't have VM Service URIs for Desktop release builds.
Right now there's not an easy way for VS Code to know whether it doesn't have a VM Service URL because the debug session has not finished starting up, or it's a release build. I think we should be able to get this though (I can see the
fluttertool does emit anapp.startedevent in the case of a release build). I've filed Dart-Code/Dart-Code#3945 to do this and improve that specific message which covers the case where DevTools won't be usable at all. I think it makes sense for the other cases - where we can spawn DevTools but that screen is not available for the current app - in DevTools by tweaking the message shown in the original screenshot at the top.DanTup commentedon Jun 22, 2022
With the latest Flutter and next VS Code extension, the message here:
Should be a bit more specific, separating "is not ready yet" from "is not available for an app running in this mode".
srawlins commentedon Sep 30, 2026
DevTools unified its debug-mode warning banners across screens via DebugModePerformanceMessage, and IDE integrations updated their messaging to clearly indicate when features are unavailable for the current run mode.
If there is more work to do here, please let us know by filing a new issue with up to date information. Thanks!