Repository navigation
Ship DevTools with dart2wasm #7856
Description
The DevTools codebase is prepared for building DevTools with dart2wasm thanks to the unblocking work here.
There are still a few requirements that we need to meet before moving this effort forward:
- Land the bootstrapping changes to DevTools in a way that does not break our g3 roll.
- CC @eyebrowsoffire @xster we will need support from the Fl@G team to fully support the new bootstrapping syntax. If adding full support is infeasible right now, we may have to workaround this by diverging the g3 bootstrapping code from the external. This is not ideal since this will cause a continued maintenance burden and potential regressions in g3, given we will not be testing externally with the same bootstrapping used in g3. See b/343786318 for tracking issue.
- Done in Reland migration to use new flutter bootstrapping methods #7865. G3 change to use legacy index.html: cl/638797386.
-
Ensure that the VS Code embedded web views support WasmGC (see background information on Chromium and V8)@DanTup can you confirm?- EDIT: This will only work if the user has set
--enable-coifor VS Code. At this time, this is not something we want to recommend because this may cause performance regressions for VS Code. Until Enable COI for desktop withcredentiallessmicrosoft/vscode#186614 is fixed, we do not expect users using DevTools embedded inside VS Code to be able to use the wasm build. See comments below for more details.
- Ensure that the IntelliJ embedded web views (JXBrowser) support WasmGC (see background information on Chromium and V8)
- @helin24 can you confirm?
- Add support for opt in / opt out behavior. See these web bootstrapping docs for an example of customizing configuration based on query parameters.
- Fixed by Add wasm opt-in setting #8270
- Add support for building DevTools with wasm and serving it from the DevTools server with the proper headers
- Add support for building with Wasm to the recipe running the automated LUCI builds of DevTools. These builds are what ships with the Dart SDK
- Ensure DevTools is shipped with source maps so that crashes from DevTools with wasm are actionable: Get stacktrace information in release build of DevTools #7392
- Ensure analytics reflect whether a user is running DevTools with wasm or not (fixed by Upgrade to unified_analytics 6.1.3 #8317)
Compare the dart2wasm DevTools build to dart2js and file any issues that come up.
Blocking:
Activity
kevmoo commentedon May 30, 2024
@kenzieschmoll – keep in mind, we can use query param magic to force loading certain versions. So if there are contexts where wasm won't work, we can just disable them. Or we can make loading the wasm version opt-in for testing, etc.
kevmoo commentedon May 30, 2024
Ha! just read your last bullet. 🤦
DanTup commentedon May 31, 2024
The current version of VS Code uses Chromium v120 which sounds like it should support this. However, I don't know if there are things in Electron/VS Code themselves that might impact the user of this. @kenzieschmoll what's the easiest way for me to build DevTools using WASM (can I do it through
devtools_tool serve? hacking scripts locally to make this work would be fine for testing).And when it is running, how do I confirm it is using the wasm version and didn't fall back to js?
kenzieschmoll commentedon May 31, 2024
Patch the changes from #7867 and https://dart-review.googlesource.com/c/sdk/+/369100. Then run
devtools_tool serve --wasm.If the wasm changes are picked up, you should see
main.dart.wasm,main.dart.mjs, andcanvaskit/skwasm.js,canvaskit/skwasm.wasmin the loaded sources. Here is what I see locally.helin24 commentedon May 31, 2024
IntelliJ uses JxBrowser version 7.38.2 currently, which includes Chromium 124.0.6367.92 and should support WasmGC.
It's hard for me to tell what version of JCEF IntelliJ uses when that option is chosen by user setting, but JCEF is a few versions behind the CEF library, which currently is using Chromium 125 (https://cef-builds.spotifycdn.com/index.html).
In summary I think either implementation of embedded browser will be fine for wasm.
xster commentedon May 31, 2024
@yjbanov the sequencing will likely be that we'll work on shipping devtools in wasm in google after we decide to ship flutter web in wasm in google3
DanTup commentedon Jun 4, 2024
@kenzieschmoll
The first has already landed but I patched in the second. I added "--wasm" to my
dart.customDevToolssetting. Inside VS Code, it seems to have loaded the JS version:However if I open in an external browser it loads the wasm version, however it throws and the app doesn't load:
I presume the first issue is that whatever is being used to detect whether wasm is available is failing. @kevmoo is there an easy way for me to review (or step through) these conditions? Looking through
flutter_bootstrap.jsI found a function that looked like it was doing that which runs:However if I run that myself in the console, it appears to return
true, so I think there may be other conditions.DanTup commentedon Jun 4, 2024
Seems like the issue is that
window.crossOriginIsolatedisfalseThe docs here confirm the headers in the CL above are required, but I see those are also set:
It's not clear to me why this value is
false. There's a similar issue at microsoft/vscode#183765 from last year about this being the case on Github.dev and a link to a private repo with a fix, which I suspect is just setting the same headers.DanTup commentedon Jun 4, 2024
I tracked this back to microsoft/vscode#186614. It seems cross-origin-isolatation is currently disabled by VS Code. When it was enabled the were performance issues that resulted in it being reverted.
I tried running
code --enable-coito force this enabled for testing, however the iframe with DevTools in it won't load at all:Which seems to be because another header is not present:
I don't know the implications of adding that header.
eyebrowsoffire commentedon Jun 4, 2024
Yes, if you're loading the app in an iframe, you will need to set a CORP header for the child document if you want cross origin isolation (which is needed for the multi-threaded rendering that the skwasm renderer does). I don't know exactly how the embedding of this works with VS Code. I think
Cross-Origin-Resource-Policy: cross-originshould be fine for this use case, as long as all the assets that devtools uses are also served withCross-Origin-Resource-Policy: cross-origin.DanTup commentedon Jun 5, 2024
Thanks! Adding that header on its own didn't work, but then I found I needed
allow="cross-origin-isolated"on the iframe. With that, the flags are all true and the wasm version is used - and fails with:This is the same error I posted above when running outside of VS Code. It's not clear to me if that's a DevTools or wasm bug?
Allow COI in DevTools iframe
Add headers to the DevTools server to enable serving DevTools with wasm.
7 remaining items
kenzieschmoll commentedon Jul 10, 2024
@DanTup now that the regression with accessing the Flutter store file has been fixed, are you able to verify whether the wasm build works properly when embedded in VS Code now?
DanTup commentedon Jul 10, 2024
cross-origin-isolate is still gated with a flag in VS Code (so normal users can't get a wasm version), but if I:
code --enable-coito enable cross-origin-isolate..add('Cross-Origin-Resource-Policy', 'cross-origin')into the DevTools servercustomDevToolsin VS Code to run with--wasmThen it loads:
However, I can't interact with the inspector.. clicking on items in the tree just doesn't do anything (no visible selection or anything). I do now have this error in the console, though it appears as the page loads (not when I click) so I'm not sure it's related:
However, if I open externally in the browser, then all is good (clicking in the inspector works), so it does seem like there's more broken in VS Code (I don't know if this might be why COI is still behind a flag or unrelated). I'll need to do some more debugging to try and figure out what's wrong here.
kevmoo commentedon Jul 10, 2024
@DanTup – the cast is likely here:
devtools/packages/devtools_app/lib/src/shared/server/_release_notes_api.dart
Line 32 in 86ef045
How hard is it to create a
_decodeBoyAsBoolfunction with some debug printing (instead of(json.decode(respo.body) as bool)– so we can see what's happening there?DanTup commentedon Jul 10, 2024
Ah, thanks for the pointer. I can just use the dev tools to see the network response - and it's a string:
Looks like this was actually fixed recently via #7997 but I didn't have a
dependency_overridein DDS to get that fix in the server.I wasn't expecting it, but re-running with that fix included I can use the inspector tree fine :)
Maybe the release notes overlay was partially there absorbing the clicks or something? 🤷♂️
So, in summary:
..add('Cross-Origin-Resource-Policy', 'cross-origin')to the DevTools server (I don't if there are security implications to consider before doing this)code --enable-coi)Then it does appear to work (at least in my limited testing of clicking around the inspector). I don't know if/when VS Code will enable COI by default though (there's an issue at microsoft/vscode#186614 that I think is related).
kenzieschmoll commentedon Jul 10, 2024
Is there a way we can detect whether this is enabled, and fallback to using the dart2js version of DevTools if it is not?
kevmoo commentedon Jul 10, 2024
@kenzieschmoll – we'll have to ask @eyebrowsoffire – or just try it out. I'm pretty sure we do automatically fallback in most failure cases, just not sure of this one.
DanTup commentedon Jul 10, 2024
This already happens, because
window.crossOriginIsolatedis false in that case and the WASM version is only selected when it's true (plus some other conditions noted further up).DanTup commentedon Jul 10, 2024
But, I think we do need to add that extra header in to the DevTools server, otherwise I think we could load the WASM version but then fail with the error shown above at #7856 (comment).
[dds] Add cross-origin-resource-policy to DevTools server to enable W…
eyebrowsoffire commentedon Jul 11, 2024
Note: We do fall back to CanvasKit + JS if
window.crossOriginIsolatedis falsekenzieschmoll commentedon Oct 3, 2024
This work is complete. DevTools + Wasm will be shipped as an opt-in feature behind a DevTools setting for the Q4 Dart / Flutter stable release. We will aim to turn this on by default for the Q1 2025 stable release, tracked here: #8395
DanTup commentedon Apr 7, 2025
@kenzieschmoll FYI, I did more testing of the wasm version in VS Code this morning, and I was unable to repro the performance issues I'd recalled (which we discussed a little in Dart-Code/Dart-Code#5367). I also tried embedding DevTools in an iframe outside of VS Code (so no Cross-Origin-Isolation) and failed to reproduce there.
I'll leave the wasm experiment on and keep an eye on it, but as things are I think the issue is gone (or, it's a much smaller issue than it was when I first hit it).
kevmoo commentedon Apr 7, 2025
That's great new @DanTup ! Thanks for reporting!