dart-lang
Unexpected paths in Flutter web error stacks
This is similar to #379, though the packages a less weird now - but they're not in the format I would expect. I'm not sure where the problem lies though (webdev, Flutter, or somewhere else - cc @grouma @jonahwilliams).
I've got a simple Flutter app that throws an exception:
https://github.com/Dart-Code/Dart-Code/blob/484ebc5836a73eb8109fcf28f539a9c3c1df5a2a/src/test/test_projects/flutter_hello_world/lib/broken.dart
If I run it with flutter run -d chrome -t lib/broken.dart This is what I get:
══╡ EXCEPTION CAUGHT BY WIDGETS LIBRARY ╞═══════════════════════════════════════════════════════════
The following _Exception was thrown building MyBrokenHomePage(dirty):
Exception: Oops
The relevant error-causing widget was:
MyBrokenHomePage
file:///Users/danny/Dev/Dart-Code/src/test/test_projects/flutter_hello_world/lib/broken.dart:34:30
When the exception was thrown, this was the stack:
dart-sdk/lib/_internal/js_dev_runtime/private/ddc_runtime/errors.dart 195:49 throw_
packages/hello_world/broken.dart 58:5 [_throwAnException]
packages/hello_world/broken.dart 53:5 build
packages/flutter/src/widgets/framework.dart 4576:28 build
packages/flutter/src/widgets/framework.dart 4502:15 performRebuild
packages/flutter/src/widgets/framework.dart 4218:5 rebuild
packages/flutter/src/widgets/framework.dart 4481:5 [_firstBuild]
packages/flutter/src/widgets/framework.dart 4476:5 mount
Everywhere that has packages/ I would expect to see package:. To the client, "packages/hello_world" is a path that doesn't match anything on disk (there is no packages folder on disk, I think this comes from the URL used to serve them to the browser). This means we don't match them up correctly to make the filenames in the stack trace clickable.
(it's probably not difficult for me to do a replacement on packages/ at the start of a line, but other tools/command line users might also be tripped up by this).
@jonahwilliams does the new flutter web workflow do any explicit stack trace mapping? To do that you have to inject a stack trace mapper on the page and register it (the exact mechanism I can't remember but we can look at how its done in webdev/build_web_compilers).
This came up again at https://github.com/Dart-Code/Dart-Code/issues/4418. Apparently Android Studio is mapping these stack frames (I presume it's making assumptions about the layout or files in web, with packages/ being for packages, dart-sdk/ being the SDK etc.).
We could do the same in the DAP, but I think it would be better fixed here (or Flutter?) so the output to the console is consistent too. I'm not sure where that work needs to be done (or how complex it is) though.
I also noticed some paths starting with just lib (neither dart-sdk/ or packages/) which I'm not sure where they come from.
@jakemac53 do you have an opinion on where the correct place to fix this is? IntelliJ is mapping them itself, but the equivalent for VS Code is now the DAP (which lives inside DDS). However I'm wondering if it should be done further up (in flutter_tools or dwds?).
I'm not sure which layer has the most information about this (for ex. who decides what's in /packages, lib/ etc.) to reduce the assumptions that need to be made. If I do it in DAP, I would be adding assumptions that /packages/foo is always the same as package:foo, and dart-sdk/ is always the same as the SDK root (and I'm not sure what lib/ is) which doesn't seem ideal if they could change (for example if in future you could host the app inside a sub-folder or you can configure this URL structure).
My guess is something related to the flutter core libraries is causing this, it seems to be giving the path relative to the entire flutter repo. My guess would be lib/ is for flutter engine (dart:ui) paths, which are also relative to the root of the flutter engine repo.
I don't have the time right now to investigate where exactly these paths are originating from unfortunately.
Generally in Dart land there is a stack trace mapper that gets injected, which cleans up some of the dart sdk paths. My guess would be flutter isn't doing the same thing, and could.
Should we move this to the Flutter repo then? (it came up again today.. I don't think I know enough to try to fix it, but if this is the wrong repo it's less likely to be spotted by someone that could).
Yeah, we can't transfer between orgs so it will have to be re-filed and this one closed