Show extension screens in the VS code sidebar DevTools dropdown

[kenzieschmoll]

Hey @DanTup, I was experimenting with how we might do this and thought I would push up a draft. This uses a fake list of extensions from the vs code sidebar stager app. We may need to tag team this feature.

I think we will need to make a request to the DevTools server directly to get the list of available extensions for a given debug session: https://github.com/flutter/devtools/blob/master/packages/devtools_shared/lib/src/server/server_api.dart/#L214. We will need to pass the root path for the given debug session to this DevTools server request. Can we get that from the [VsCodeDebugSession] object? If we can add the data there, that would be much simpler than having to spin up another VM service connection just to detect the root path of the main isolate.

[DanTup]

Cool! I'm a little less sold on my reversal of alignment/icons in the menu with a sub-menu though.. it looks a little odd, but I don't have any suggestions to improve it 🙃

We will need to pass the root path for the given debug session to this DevTools server request.

I think we should be able to get this - but it might not be guaranteed to always be there (for example, you can create a launch config that just runs a loose .dart file that might not have any pubspec.yaml in the path). Probably we should make it optional and just not show any extensions if it's not set (and I'll ensure we only skip it in those odd edge cases).

(we need to handle it missing anyway for older versions of VS Code that aren't sending it)

[DanTup]

I've made some Dart-Code changes (Dart-Code/Dart-Code@84e75c0) to provide a projectRootPath (String?) in the session info. I've opened #6715 to add fields to add to the API here.

I've also pushed the change in a Dart-Code pre-release (v3.77.20231111) since I'm not sure if you'll hit limits using the mock/simulated environment and might want to try it for real.

Note: I have not done any testing for what happens if you call openDevToolsPage() with a page that isn't known to VS Code yet. You might get lucky and it'll work, but I suspect it'll need changes. I've opened Dart-Code/Dart-Code#4835 to track this. If we do need changes, we'll need to add a capability to VS Code to allow DevTools to know it's allowed to try to do this.

[kenzieschmoll]

Here's what the UI looks like with the standard directionality:

[kenzieschmoll]

I pushed up some changes now that we have the root path of a debug session. I have only tested this in the mock environment so I'm not sure how this works with real debug sessions. Here's what the vs code api event looks like when selecting an extension screen to open:

We'd want either an embedded iFrame or if that isn't possible, DevTools in the browser to then open to a url like:
http://localhost:64410/foo_ext?uri=ws://127.0.0.1:49216/QvpD61Jqhyc=/ws

[DanTup]

I'm trying to run this to test the current behaviour, but I keep hitting this issue. I'm running with latest Flutter master, this branch for DevTools, and using a path dependency to get the latest devtools_extensions for my extension:

[DanTup]

I think the handling of required fields might be incomplete.. When I miss only path, it triggers this error:

'Missing required fields ${diff.toString()} in the extension '

But isPubliclyHosted is parsed as a boolean from a string always, so an exception occurs way before if that's missing.

Anyway, the reason for my error was likely that my project was out of date. Using the e2e example with some rigging of the config, I got further:

And it triggered a new browser window when clicked:

I think that error is because the way I rigged my config was only for the sidebar and doesn't apply here. I'll do some more digging later though.

It's promising that it opened in an external window rather than failed, because it means even if we fix it to open embedded, we don't need any capabilities for this, the current behaviour is better than disabling it (assuming we can fix the above).

[kenzieschmoll]

for the issue with isPubliclyHosted make sure you local Dart SDK is also on the latest master and that you have run dart pub upgrade on sdk/pkg/dds.

[DanTup]

for the issue with isPubliclyHosted make sure you local Dart SDK is also on the latest master and that you have run dart pub upgrade on sdk/pkg/dds

Seems like when I'm running devtools_tool serve it downgrades devtools_shared back to 6.0.0:

[4:50:10 PM] [DevTools] [Info] <== C:\Dev\Google\dart-sdk\sdk\pkg\dds > dart pub get
[4:50:10 PM] [DevTools] [Info] <== Resolving dependencies...
[4:50:10 PM] [DevTools] [Info] <== < devtools_shared 6.0.0 (was 6.0.1) (6.0.1 available)
[4:50:10 PM] [DevTools] [Info] <== Changed 1 dependency!

This happens even if I set ^6.0.1 explicitly in its pubspec. I tried using a dependency_override so DDS would use the version from my DevTools clone, but that fails

[4:59:47 PM] [DevTools] [Info] <== [serve] serving DevTools with a local devtools server...
[4:59:47 PM] [DevTools] [Info] <== C:\Dev\Google\dart-sdk\sdk > dart pkg\dds\tool\devtools_server\serve_local.dart --devtools-build=C:\Dev\Google\devtools\packages\devtools_app\build\web --machine --machine --allow-embedding
[4:59:49 PM] [DevTools] [Error] ../../devtools/packages/devtools_shared/lib/devtools_shared.dart:1:1: Error: The specified language version is too high. The highest supported language version is 3.1.
// Copyright 2020 The Chromium Authors. All rights reserved.
^
../../devtools/packages/devtools_shared/lib/src/devtools_api.dart:1:1: Error: The specified language version is too high. The highest supported language version is 3.1.
// Copyright 2019 The Chromium Authors. All rights reserved.

I'm wondering if I have some bad versions of things being picked along the day (such as the build above maybe just called "dart" that might be taking stable from PATH). I'll try moving my stable things away so there's only one version of everything and see where I get.

[DanTup]

Ok, I got this working - I think the dependency_override in DDS for devtools_shared is what was required (and a bad version of dart/flutter caused the other failures when I tried this above).

Opening an extension does work - though currently in an external window:

ext.mp4

We can look at supporting embedded, but I think this is good enough for now.

One thing to note though (and this may or may not be expected), the extensions did not show up in the list when running in the sidebar (they did show up if I opened DevTools in an external window where it had a VM Service connection). To test opening the page above I had to hard-code the extension in the nav:

[kenzieschmoll]

Opening an extension does work - though currently in an external window

Great! can we remove embed=true when launching in an external window?

the extensions did not show up in the list when running in the sidebar

How can I reproduce this locally with a locally running DevTools server and locally running DevTools app in the sidebar?

[DanTup]

Great! can we remove embed=true when launching in an external window?

Oops, good catch - fixed!

How can I reproduce this locally with a locally running DevTools server and locally running DevTools app in the sidebar?

This might change slightly depending on the outcome of discussion on Discord, but for now:

1. Make sure you're on the latest pre-release of the Dart extension (I'm going to push v3.77.20231116 shortly)
2. Open a Flutter project (that has a DevTools extension) and open the Workspace Settings and set it to use custom DevTools:

   "dart.customDevTools": {
   	// Path to the DevTools repo root
   	"path": "C:\\Dev\\Google\\devtools",
   	"env": {
   		// Path to the Dart SDK repo
   		"LOCAL_DART_SDK": "C:\\Dev\\Google\\dart-sdk\\sdk",
   		// Path to the version of Flutter DevTools is pinned to
   		"FLUTTER_ROOT": "C:\\Dev\\Google\\devtools\\tool\\flutter-sdk"
   	}
   },
   // Enable the log for debugging in case DevTools fails to start
   "dart.devToolsLogFile": "logs/devtools.txt",

3. Run the Developer: Reload Window command
4. It'll take a little while to start up custom DevTools (it's running a build in the background - I will add support for skipping the update checks to speed this up a little, but have not yet)
5. You should now have the version of Sidebar from source.. run an app and the menu should contain the extensions (assuming the bug that required me to hard-code them in the menu is fixed)

[kenzieschmoll]

I tested locally and verified the extensions list shows up as expected:

[kenzieschmoll]

@DanTup where is the best place to test this functionality? I didn't see where the sidebar is tested in the devtools/ repo. Do we have testing in the Dart-Code plugin?

[DanTup]

@DanTup where is the best place to test this functionality? I didn't see where the sidebar is tested in the devtools/ repo. Do we have testing in the Dart-Code plugin?

We don't have many tests for this yet. When we first added it it seemed like there was going to be more design input and I was waiting to try and minimize the changes needed to tests. I'm not sure what happened about that though and I got busy with other things 😔

Testing the actual contents of the sidebar (eg. things inside the webview) from Dart-Code is tricky (and would probably make catching issues a slow round-trip) so I think it's better to have those for functionality here. The mock VS Code environment has a kind of mock version of the VS Code API that would probably help with these tests.

[DanTup]

Nice, LGTM :)

[kenzieschmoll]

@DanTup I added tests, can you please review? thanks

[DanTup]

Looks great, thanks!