Repository navigation
Sidebar DevTools not working in IDX/Firebase Studio #5158
Description
Describe the bug
When opening a remote VSCode or CodeOSS Workspace, the Flutter DevTools in the sidebar fails to load. It appears to be assuming it has access to a server on localhost, which is not the case for remote workspaces.
To Reproduce
This should be reproducible in any remote workspace, but is trivial to reproduce using IDX.
Steps to reproduce the behavior:
- Create a new workspace in IDX
- Click on the Flutter extension icon in the activity bar
- Wait for the "Flutter Sidebar" to load with the failure shown below
Expected behavior
The Flutter Sidebar functionality should be shown for remote workspaces, or the section should not be visible if the functionality cannot be supported remotely.
Screenshots
Please complete the following information:
You can run the Dart: Collect Diagnostic Information command from the VS Code command palette (F1) to easily capture this information or provide it manually.
- Operating System and version: N/A
- VS Code version: Tested on Project IDX 1.83.1
- Dart extension version: v3.90.0
- Dart/Flutter SDK version: Flutter 3.22.2 | Dart 3.4.3 | DevTools 2.34.3
- Target device (if the issue relates to Flutter debugging): N/A
Activity
Ensure sidebar URL is exposed so it works with remove extension hosts
Expose the DTD URL before passing to DevTools server
DanTup commentedon Jun 28, 2024
I pushed a fix to ensure the sidebar URL is passed through
exposeUrl()and it gets further, but it fails because the sidebar is trying to connect to the Dart Tooling Daemon and that URL is also unexposed:So I made a change (d7c9150) to expose the DTD URI before we pass it to DevTools (I'm not sure this is safe yet, but I did it for testing) and it gets further - it claims it's connected to DTD, but then it fails with a WebSocket error:
Unfortunately the error is not very useful and there's nothing more useful in the Network log. I don't know if this is an IDX issue, or DevTools/DevTools server. I've reverted that change for now until I have a better idea what's wrong.
@kenzieschmoll does (or will in future) DevTools server connected to DTD directly, or does the URI only be given to the client web app? If it needs to connect itself, then we might need to update the server to accept two URIs - one local, and one public.
When running in a cloud IDE, there are two machines in play - the client web browser ("client") where the VS Code UI is running (and which contains webviews for things like DevTools/sidebar) and then the remote container ("server"). For everything running in the server (Dart-Code, DevTools server), DTD can be connected to on
localhost.. but for the UI running in the users browser, we have to ask the cloud IDE to expose a port and give us back a URL that is tunnelled though (this might look likehttps://9100-idx-my-test-sidebar-app-171680.cluster-4ezwabcvdojawstf2k7vqy36oe6.cloudworkstations.dev/which may map tolocalhost:9100in the container).The DevTools UI needs to use the public URI to connect to any services (because they're not accessible on
localhostfrom the users browser) but any direct connections probably need to still uselocalhost. So if DevTools server may use the URI for more than just feeding to the web app, we might need to give it both URIs so it can use the correct one for each use.DanTup commentedon Jun 28, 2024
@kenzieschmoll also, I thought DevTools was no longer minified so I tried changing to the master channel to see if I got a more useful stack trace, but it seemed the same on master. Did I misremember?
pdblasi-google commentedon Jun 28, 2024
@DanTup There is a known issue in GCW where SSE connections aren't supported that has affected DevTools historically, so you may be blocked on that for a full fix.
We had a workaround for a while using a custom fork that used WebSockets instead, but had to drop the custom fork for maintenance reasons and because we weren't sure what other effects switching to WebSockets may have had downstream.
We've been continuing to push for SSE support from the GCW team, so the
exposeUrl()fix should eventually be enough to resolve this issue if you'd rather not pursue switching from SSE connections at the moment.DanTup commentedon Jul 1, 2024
I'm not sure I understand - do you mean neither WebSockets or SSE works, or should WebSockets work? (the error seems to be WebSockets, not SSE... I was sure we could use full WebSockets for all the Dart/Flutter tools because we'd had some SSE issues on other cloud platforms).
pdblasi-google commentedon Jul 1, 2024
SSE is the protocol that's currently unsupported on GCW.
Our workaround was that we forced the protocol for dev tools to use wss protocols. We had to drop the forked version not because of wss, but because of the maintenance costs of maintaining the fork and our changes to it.
DanTup commentedon Jul 1, 2024
I see. But does this mean your understanding is that WebSockets are fully supported? The error above seems to be a WebSocket error, but I don't know if it's an infrastructure issue or something else. If WebSockets should work, I'll try to do some more debugging. I do recall on some cloud IDEs many requests would go through some authentication/redirects that would often break these kinds of connections, but I don't know if that's what's happening here (I think mostly that was an issue with the Dart debug extension where requests wouldn't get the auth cookies a normal request from a browser tab would).
pdblasi-google commentedon Jul 1, 2024
Apologies, I didn't write the original workaround, so I'm not completely familiar with why the changes that were made work. From what I can gather from the patch, these are the changes we made:
80-in the host to be{n.port}-insteadI'm not sure if these workarounds are still relevant, but those are the two major changes we had in place.
DanTup commentedon Aug 27, 2024
There are likely multiple issues here. A few issues were fixed above for mapping the URI used in the iframe, however the DTD connection fails from the browser because that's not mapped.
The next step is to make the DevTools server accept a pair of DTD URIs (an internal and external one) and provide the correct one to the front-end. Once the server supports it, Dart-Code can pass both.
There may be some additional issues with the use of SSE, but it may be easier to validate that with the rest working. There's an existing issue at flutter/devtools#2892 that is tracking working with proxies that don't support SSE.
9 remaining items
DanTup commentedon Nov 25, 2024
I tested this again on latest code to see what things look like now. Both the stack trace and the error are still minified though so it's not clear what the underlying issue is. If I paste that
wss:URL into my browser address bar withhttps, I get a 404 back which I'm not sure if is indicative of the problem (the network tab doesn't seem to give any indication of this).@kenzieschmoll any ideas if we can get a better error message from this? I recall you saying there were some changes that would improve this, though I'm not sure if they were just stack traces or if would cover the runtime error messages anyway?
kenzieschmoll commentedon Nov 25, 2024
The most recent change that would have affected stack traces is flutter/devtools#8510 but this would have only affected the stack traces sent to analytics. So if you were running DevTools from tip of source, then you would have all the recent updates to improve stack traces for runtime exceptions.
Looks like the exception is probably coming from package:web_socket_channel. @elliette any idea why we'd still be getting "Instance of minified" after your changes to show non-minified stack traces using the source maps?
elliette commentedon Nov 27, 2024
This is the change that added the stack trace mapping to DevTools: flutter/devtools#8385
I just checked that serving DevTools and triggering an error does show the unminified errors, so I don't think we've regressed here:
I also see that
web_socket_channelis included inmain.dart.js.map:My only guess is that perhaps this is an error that was triggered from outside the error-handling zone: https://github.com/elliette/devtools/blob/8f31a286c352465673e5f8668247efe4096d0d8d/packages/devtools_app/lib/src/framework/app_error_handling.dart#L32
Do the VS Code side panels have a different entry point than the main DevTools entrypoint (https://github.com/flutter/devtools/blob/3e5327a02693b1405359dc5322d7f0a40151b9b7/packages/devtools_app/lib/initialization.dart#L27)? That would explain why we don't have the error handling for them.
DanTup commentedon Feb 12, 2025
@elliette apologies, apparently I never responded to your question above.
As far as I can tell, they don't. It's a different "page" in DevTools (
StandaloneScreenType.editorSidebar) but as far as I can tell, DevTools is all initialized the same, and just the page contents are different (handled via routing).[-]Sidebar DevTools not working in remote space[/-][+]Sidebar DevTools not working in IDX/Firebase Studio[/+]DanTup commentedon Sep 10, 2025
There have been many issues here and I believe #5680 (which was in pre-release v3.119.20250909 and will be included in the next stable release) solves the remaining one. Here's a screenshot with the Sidebar, Flutter Inspector and Property Editor all loaded in Firebase Studio today (using 3.119.20250909).
If there are still issues after this version, we should open new specific issues for them.