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
Open embedded DevTools Inspector to error-causing widget for Flutter render overflow errors #3088
As of flutter/flutter#74251, deep links to the inspector are printed in error messages for render overflow errors. The structured error for this will contain a diagnostics node of type DevToolsDeepLinkProperty (the diagnostics node naming is in progress flutter/flutter#74455). Right now the diagnostics node looks like:
upon receiving an error like this, show a prompt that warns the user that something went wrong and gives them a button to inspect the error-causing widget in the embedded DevTools inspector.
take over the rendering of this diagnostics node in the console. We don't want a link in the console that will take the user to the chrome version of DevTools at the same time that we show a prompt that will take the user to the embedded version of DevTools.
Generally, show the link in the console as is if the user is not opted into embedded DevTools, and do not show the link in the console if we are using the prompt
We need an MVP of this by end of next week, if possible (for demo recording purposes). Ideally to be included in the release next week.
What if there are multiple errors at once? Do we collapse the notifications? Always show the last?
Provide users with an option "Don't show me messages like these" or similar. If the user does this, we should revert back to displaying the deep link in the console.
Here's how this shows up now, including the text replacement:
What if there are multiple errors at once? Do we collapse the notifications? Always show the last?
Currently I'm preventing another from appearing for 5 seconds after one appears (unless you close it) to try and avoid them flashing in VS Code (if they have the same text, the new one would replace the previous, but it would animate and look spammy if it has firing a lot). I've done this assuming the inspectorRef from the first one would still be valid. If that's not the case, let me know and I'll remove this so they just get replaced (it'll result in the animation replaying, but that would be better than a broken button).
Provide users with an option "Don't show me messages like these" or similar. If the user does this, we should revert back to displaying the deep link in the console.
Done! This is stored as a VS Code user setting, so the user can easily toggle it on/off from the settings too.
@kenzieschmoll I wasn't planning on including this in this months release as it's only activated when passing --devtools-server-address to Flutter and I haven't merged that yet (I need a good version number to know when it's safe to pass but I don't think there's been one since it landed). If you think it should definitely be included, let me know and I'll check again for a version number before releasing.
I wasn't planning on including this in this months release as it's only activated when passing --devtools-server-address to Flutter and I haven't merged that yet (I need a good version number to know when it's safe to pass but I don't think there's been one since it landed).
@helin24 gated the change off of the correct flutter version here: flutter/flutter-intellij#5176. If we can get both passing the --devtools-server-address and the notification for overflow errors landed in VS code for this release, that would be good for consistency between the two tools.
@kenzieschmoll should --devtools-server-address be supported for flutter attach? I found a bug where I was trying to send it to all flutter invocations (flutter run, flutter test, flutter attach). I've changed this to only flutter run, though perhaps attach should be supported?
@kenzieschmoll I think I misread the error when I tested at the terminal - the one for flutter test said "Could not find an option named" and the one for flutter attach said "Missing argument for" 🤦♂️
So I think it's work as expected, and I'll remove the exclusion for attach here and only exclude test. Sorry for the confusion!
Perfect - thanks. One question - if a user clicks never ask, do we go back to showing the user the deep link as part of the error message in the console?
@kenzieschmoll we do, although only from the next debug session (although the popups will be immediately suppressed).
The settings are sent to the debug adapter at the start of a session (the debug adapter rewrites the message) but the UI/extension code is in a completely separate process, so it's a little complicated to update during a session (though it is possible).
Activity
DanTup commentedon Jan 26, 2021
Here's how this shows up now, including the text replacement:
Currently I'm preventing another from appearing for 5 seconds after one appears (unless you close it) to try and avoid them flashing in VS Code (if they have the same text, the new one would replace the previous, but it would animate and look spammy if it has firing a lot). I've done this assuming the
inspectorReffrom the first one would still be valid. If that's not the case, let me know and I'll remove this so they just get replaced (it'll result in the animation replaying, but that would be better than a broken button).Done! This is stored as a VS Code user setting, so the user can easily toggle it on/off from the settings too.
@kenzieschmoll I wasn't planning on including this in this months release as it's only activated when passing
--devtools-server-addressto Flutter and I haven't merged that yet (I need a good version number to know when it's safe to pass but I don't think there's been one since it landed). If you think it should definitely be included, let me know and I'll check again for a version number before releasing.Show notifications for widget errors that can launch the inspector
kenzieschmoll commentedon Jan 26, 2021
FYI here is the landed implementation in the flutter intellij plugin flutter/flutter-intellij#5207
kenzieschmoll commentedon Jan 26, 2021
@helin24 gated the change off of the correct flutter version here: flutter/flutter-intellij#5176. If we can get both passing the
--devtools-server-addressand the notification for overflow errors landed in VS code for this release, that would be good for consistency between the two tools.DanTup commentedon Jan 26, 2021
Aha, thanks - I thought the versions weren't comparable until the dev release, but that looks simple enough - thanks!
Show notifications for widget errors that can launch the inspector
Show notifications for widget errors that can launch the inspector
DanTup commentedon Jan 27, 2021
@kenzieschmoll should
--devtools-server-addressbe supported forflutter attach? I found a bug where I was trying to send it to allflutterinvocations (flutter run,flutter test,flutter attach). I've changed this to onlyflutter run, though perhapsattachshould be supported?DanTup commentedon Jan 27, 2021
@kenzieschmoll I merged this and published a new beta here: https://github.com/Dart-Code/Dart-Code/releases/tag/v3.19.0-beta.2
Provisional release notes here: https://dartcode.org/releases/v3-19/
kenzieschmoll commentedon Jan 27, 2021
flutter attach should support the flag as well 🤔 I'll look into it - thanks for the heads up.
DanTup commentedon Jan 27, 2021
@kenzieschmoll I think I misread the error when I tested at the terminal - the one for
flutter testsaid "Could not find an option named" and the one forflutter attachsaid "Missing argument for" 🤦♂️So I think it's work as expected, and I'll remove the exclusion for attach here and only exclude test. Sorry for the confusion!
Allow --devtools-server-address for `flutter attach`
kenzieschmoll commentedon Jan 27, 2021
Perfect - thanks. One question - if a user clicks never ask, do we go back to showing the user the deep link as part of the error message in the console?
DanTup commentedon Jan 27, 2021
@kenzieschmoll we do, although only from the next debug session (although the popups will be immediately suppressed).
The settings are sent to the debug adapter at the start of a session (the debug adapter rewrites the message) but the UI/extension code is in a completely separate process, so it's a little complicated to update during a session (though it is possible).