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
Sidebar does not load on current Flutter master #5049
@kenzieschmoll@jacob314 FYI... I haven't tracked down what this is yet (the error isn't very useful and doesn't tell me what frame it tried to access), but I tested with stable and it doesn't occur there, so it seems like something different in Flutter and/or DevTools and not VS Code or Dart-Code.
We do have CSP rules set on the iframe, but from the error I'm not sure this is a CSP issue (usually the error is quite clear for them).
Error: Blocked a frame with origin "http://127.0.0.1:9100" from accessing a cross-origin frame.
at Object.getNativeInterceptor (http://127.0.0.1:9100/main.dart.js:234:24)
at Object.getInterceptor$ (http://127.0.0.1:9100/main.dart.js:404:16)
at Rti._isTestViaProperty [as _is] (http://127.0.0.1:9100/main.dart.js:9227:18)
at Rti._generalNullableIsTestImplementation [as _is] (http://127.0.0.1:9100/main.dart.js:9218:28)
at Rti._generalNullableAsCheckImplementation [as _as] (http://127.0.0.1:9100/main.dart.js:9255:24)
at DartToolingApiImpl_DartToolingApiImpl$postMessage_closure.call$1 (http://127.0.0.1:9100/main.dart.js:196557:48)
at StaticClosure._rootRunUnary (http://127.0.0.1:9100/main.dart.js:11263:18)
at _CustomZone.runUnary$2$2 (http://127.0.0.1:9100/main.dart.js:110937:39)
at _CustomZone.runUnaryGuarded$1$2 (http://127.0.0.1:9100/main.dart.js:110870:14)
at _ControllerSubscription._sendData$1 (http://127.0.0.1:9100/main.dart.js:109990:19)
Based on DartToolingApiImpl_DartToolingApiImpl$postMessage_closure I suspect this might be DTD related - though it says "from accessing a cross-origin frame"... does DTD integration in DevTools make use of frames?
I misread this, it says "Dart Tooling API" which is the sidebar API and unrelated to DTD.
However, there doesn't seem to be any frames here so the error is strange, it's just calling postMessage and the purpose of postMessage is supposed to be to allow cross-origin communication? 🤔
Following up from our discussion there (thanks for the code btw!), I think the culprit is the type check on the result of parent (which is the cross-frame object I believe):
var t1 = type$.nullable_JavaScriptObject._as(type$.JavaScriptObject._as(self.window).parent);
I actually don't see this on master for some reason, but I believe that's because there are some optimization flags eliding the type checks. From a convo with @sigmundch, it seems like there may have been a recent change in the optimization flags (from -O4 to -O1) with devtools. If changing it back or using profile mode is possible, I believe this issue would go away.
Alternatively, if we can't, we can try out some dart2js pragmas here to unsafely cast and avoid the above issue. For example,
@pragma('dart2js:tryInline')
@pragma('dart2js:as:trust')
TunsafeCast<T>(Object? o) => o asT;
...
final parent =unsafeCast<JSObject?>(window.getProperty<JSAny?>('parent'.toJS));
if (parent !=null) parent.callMethod('postMessage', ...);
We may even be able to avoid callMethod and use the postMessagepackage:web member by just unsafely casting to Window?.
From a convo with @sigmundch, it seems like there may have been a recent change in the optimization flags (from -O4 to -O1) with devtools. If changing it back or using profile mode is possible, I believe this issue would go away.
I don't know the answer to this - I presume the change you refer to is flutter/devtools@4208a62 which based on comments at flutter/devtools#7335 may have been done to improve things like stack traces when there are errors in the wild?
@elliette@kenzieschmoll do you have any thoughts on this? It sounds like changing the optimization back might be a nicer change than flutter/devtools#7476 to avoid this issue for now, but it might make debugging issues from users more difficult.
Otherwise, we can try something like the code above (assuming that's better than putting dart:html back in).
Yes I believe that's the one. If minification is the issue, we can disable minification but still keep the other optimizations.
Putting dart:html back will likely affect the Wasm story here, so I'd prefer using the suggestion in the above comment if adding back optimizations isn't viable. (note that none of this addresses the long-term issue of dealing with cross-origin objects, that still requires work on my part)
Activity
DanTup commentedon Mar 27, 2024
@kenzieschmoll @jacob314 FYI... I haven't tracked down what this is yet (the error isn't very useful and doesn't tell me what frame it tried to access), but I tested with stable and it doesn't occur there, so it seems like something different in Flutter and/or DevTools and not VS Code or Dart-Code.
We do have CSP rules set on the iframe, but from the error I'm not sure this is a CSP issue (usually the error is quite clear for them).
DanTup commentedon Mar 27, 2024
Here's the stack as text:
Based onDartToolingApiImpl_DartToolingApiImpl$postMessage_closureI suspect this might be DTD related - though it says "from accessing a cross-origin frame"... does DTD integration in DevTools make use of frames?I misread this, it says "Dart Tooling API" which is the sidebar API and unrelated to DTD.
However, there doesn't seem to be any frames here so the error is strange, it's just calling
postMessageand the purpose ofpostMessageis supposed to be to allow cross-origin communication? 🤔https://github.com/flutter/devtools/blob/4eab4b3cb2b85286ec51f12a6d3904a93870f6f9/packages/devtools_app/lib/src/standalone_ui/api/impl/dart_tooling_api.dart#L57
DanTup commentedon Mar 27, 2024
Looks like this might be dart-lang/sdk#54938
Switch back to dart:html for postMessage
srujzs commentedon Mar 27, 2024
Following up from our discussion there (thanks for the code btw!), I think the culprit is the type check on the result of
parent(which is the cross-frame object I believe):I actually don't see this on master for some reason, but I believe that's because there are some optimization flags eliding the type checks. From a convo with @sigmundch, it seems like there may have been a recent change in the optimization flags (from
-O4to-O1) with devtools. If changing it back or using profile mode is possible, I believe this issue would go away.Alternatively, if we can't, we can try out some dart2js pragmas here to unsafely cast and avoid the above issue. For example,
We may even be able to avoid
callMethodand use thepostMessagepackage:webmember by just unsafely casting toWindow?.DanTup commentedon Mar 27, 2024
I don't know the answer to this - I presume the change you refer to is flutter/devtools@4208a62 which based on comments at flutter/devtools#7335 may have been done to improve things like stack traces when there are errors in the wild?
@elliette @kenzieschmoll do you have any thoughts on this? It sounds like changing the optimization back might be a nicer change than flutter/devtools#7476 to avoid this issue for now, but it might make debugging issues from users more difficult.
Otherwise, we can try something like the code above (assuming that's better than putting
dart:htmlback in).srujzs commentedon Mar 27, 2024
Yes I believe that's the one. If minification is the issue, we can disable minification but still keep the other optimizations.
Putting
dart:htmlback will likely affect the Wasm story here, so I'd prefer using the suggestion in the above comment if adding back optimizations isn't viable. (note that none of this addresses the long-term issue of dealing with cross-origin objects, that still requires work on my part)DanTup commentedon Mar 27, 2024
I presume this would be done by removing
-O1and just adding--no-minify?I can test that in the morning and if it works update my PR (assuming Elliott/Kenzie don't see any reason not to fix it that way).
Thanks!
DanTup commentedon Mar 27, 2024
Oh, looks like there's some related discussion in flutter/devtools#7392 too.
elliette commentedon Mar 27, 2024
Just chatted with @kenzieschmoll - I'm going to open up a PR to switch to building with
--profileand we will get that into the releaseelliette commentedon Mar 27, 2024
Here's the PR: flutter/devtools#7485
Confirmed it fixes the infinite spinner
DanTup commentedon Mar 27, 2024
@elliette awesome, thank you!
sigmundch commentedon Mar 27, 2024
Thanks all for connecting the various threads together!
elliette commentedon Mar 28, 2024
We missed the branch alignment cut-off by 30 minutes, but I've opened a cherry-pick request for it: dart-lang/sdk#55327
DanTup commentedon Apr 17, 2024
This was fixed - verified on the current Flutter beta (to test the cherry-pick):