Experimental: Support embedding DevTools in Sidebar views instead of Editor views - #5367

@kenzieschmoll while testing this on Flutter master, I frequently trigger this crash (DevTools entirely stops rendering and the console filles with tons of errors):

However, I can't repro when running from latest source with customDevTools. Do you know of anything that might explain this (either the error, or that it isn't occurring from source)? I'm not sure whether to ignore and assume whatever it was has been fixed, or to keep digging.

For reasons I can't explain, it only happens when embedded in the sidebar, and not embedded as an editor (even though I can't think of any reason these should differ, they've both just iframes hosted somewhere inside VS Code's UI).

(I'm also curious about the wasm mentioned in the stack... I thought that VS Code didn't support Cross-Origin Isolation and so we wouldn't get WASM anything 🤔)

does this happen if you disable the wasm setting from the DevTools settings menu? You can also delete "experiment.wasm": "true", from ~/.flutter-devtools/.devtools to disable the setting.

Ok, it appears that:

• it does not occur with wasm disabled
• I can actually reproduce it with DevTools in the old editor pane (I don't know why I failed yesterday, but it was quite easy today)

I was surprised that we're seeing wasm load here - microsoft/vscode#186614 is still open, but I see a change that seems like it might have enabled this. I've pinged on there to find out what the exact status is.

I'll do some more testing and see if I can repro this from source. I don't think this issue is related to moving to the sidebar anymore though, so it shouldn't hold this up.

@kenzieschmoll still failing to repro this when running from source. Is there much different that dart.customDevTools (dt server) does compared to the build that gets rolled into the SDK? I'm trying to figure out whether this might just have been fixed recently, or if there is some difference in the SDK-shipped build compared to what I'm running.

@kenzieschmoll does ?wasm=true force WASM, even if the normal browser checks don't pass? Based on the response at microsoft/vscode#186614 (comment), VS Code hasn't yet enabled COI, and if I evaluate window.crossOriginIsolation I still see false (which previously was a requirement for wasm - see flutter/devtools#7856 (comment)).

This makes me wonder if the errors seen here are a result of not supporting everything wasm needs (which might be why I can't repro outside of VS Code, since Chrome does support it?).

If wasm is not supported, the JS fallback should automatically be used. If this is not happening, then maybe there is a bug in the fallback logic, @eyebrowsoffire?

If wasm is not supported, the JS fallback should automatically be used.

This doesn't seem to be happening - we seem to be getting the wasm version anyway. Disabling the DevTools experiment does stop it from happening. Does ?wasm=true intentionally override checks for things like window.crossOriginIsolation?

All that the query parameter does is determine whether we set {renderer: 'canvaskit'} in the flutter bootstrap config: https://github.com/flutter/devtools/blob/master/packages/devtools_app/web/flutter_bootstrap.js/#L83

When wasm=true is present, we do not pass a renderer, and since DevTools was built with the --wasm flag, it uses wasm by default in this case.

Skwasm has a (recently added) single-threaded renderer mode that works in a non-COI context, so in a Chromium browser with a non-COI context, we will fall back to the single-threaded renderer instead of falling all the way back to dart2js+canvaskit. So that fallback behavior is expected.

If you're reproducing this while building from source, is it possible to build devtools with flutter build web --wasm --debug so that we get some more readable error messages?

If you're reproducing this while building from source, is it possible to build devtools with flutter build web --wasm --debug so that we get some more readable error messages?

@DanTup if you pass --build-mode=debug to the dt serve command (and possibly --no-strip-wasm too?) that should help with the stack traces.

Skwasm has a (recently added) single-threaded renderer mode that works in a non-COI context, so in a Chromium browser with a non-COI context, we will fall back to the single-threaded renderer instead of falling all the way back to dart2js+canvaskit. So that fallback behavior is expected.

Ah, that explains that then :)

If you're reproducing this while building from source, is it possible to build devtools with flutter build web --wasm --debug so that we get some more readable error messages?

So far I haven't been able to repro from source, only a pre-built SDK. However I don't see why that should matter, so I will keep trying.

I only see this crash inside VS Code and when using WASM, so I wonder if it may be related to that mode. Is there any way to force it (the single-threaded rendered) in normal Chrome? Debugging inside VS Code is a bit of a pain :-)

(I guess it's also possible the Chrome version difference is related - VS Code is Electron and lags a bit behind Chrome - it's currently Chromium 128)

@DanTup

I only see this crash inside VS Code and when using WASM, so I wonder if it may be related to that mode. Is there any way to force it (the single-threaded rendered) in normal Chrome? Debugging inside VS Code is a bit of a pain :-)

Yes! You can pass the forceSingleThreadedSkwasm: true flag in the flutter configuration object (the same way the renderer is passed, for example).

@DanTup

(I guess it's also possible the Chrome version difference is related - VS Code is Electron and lags a bit behind Chrome - it's currently Chromium 128)

There was actually an issue in Chromium 128, I'm not sure if a hotfix was put in or if it's the same thing you're seeing:
https://issues.chromium.org/issues/368241691

There was actually an issue in Chromium 128, I'm not sure if a hotfix was put in or if it's the same thing you're seeing:
https://issues.chromium.org/issues/368241691

Oh, interesting. Also - I'm struggling to repro right now... There was a VS Code update yesterday, and I also pulled latest changes from Flutter. I wonder if one of those has affected it. I'll see if I can get back to a broken state and figure out if one of those fixed it (if so, there might be no issue here now).

I've tried multiple versions of Flutter and have been unable to repro. According to https://github.com/ewanharris/vscode-versions, the version of Chromium is the same in yesterday's release as the whole of the previous month, so I'm not sure that explains it (unless something in VS Code itself changed that might impact this).

I'll keep trying to repro as I work further on this, and if I see it again I'll open a specific issue for it (since it's not related to this PR).

I managed to work around the VS Code issue that was blocking this so I'm merging as-is (it's behind a flag so it will be possible for others to try it out) and using #5396 to track the remaining issues.