Describe the bug
Breakpoints work only inside the main method
To Reproduce
Steps to reproduce the behavior:
Create breakpoints all over project files. Hit F5
Expected behavior
Execution pauses at every breakpoint with proper code.
Screenshots
Versions (please complete the following information):
Are you able to provide a code sample that triggers this? I tested a few samples and everything seems to behave ok, for example:

Ok, I've never done this, but I'll try my best. For rudimentary proof that it isn't working, you could look at this clip. For the reas
A code snippet with the aforementioned issue is (in trying.dart):
class LineGraph extends StatelessWidget {
final List<charts.Series> seriesList;
final bool animate;
LineGraph(this.seriesList, {this.animate = true});
@override
Widget build(BuildContext context) {
return charts.LineChart(seriesList,
defaultRenderer:
charts.LineRendererConfig(includeArea: true, stacked: true),
animate: animate);
}
/// Creates a [LineChart] with sample data and no transition.
factory LineGraph.withSampleData() {
print("I hope breakpoint works");
return LineGraph(
_mySampleData(),
// Disable animations for image tests.
animate: true,
);
}
static List<charts.Series<DayPose, int>> _mySampleData() => [
MonthPose_DailyData.random()
.as_chartsSeries(charts.MaterialPalette.lime)
];
/// Create one series with sample hard coded data.
}
The way its called is as follows:
main.dart file, I do part 'trying.dart';part), from which I (indirectly) call LineGraph.withSampleData().Apologies for not being more open, but I don't have the freedom to share the entire repo. Also, this is my first time putting code in an issue. My apologies for it being hard to read.
@skateboarder at 10s in that video, it looks like you clicked "Run without Debugging". It's not clear if you cancelled this and re-ran it, but running without debugging would prevent breakpoints from working - can you confirm if that was the case?
Otherwise, could you try:
Thanks!
If nothing useful there - are you able to try and reproduce this in a small sample project that you could share?
Thank you for the quick and helpful response. I created a small sample project to reproduce the issue, hope this helps.
Execute flutter run --no-sound-null-safety in order to run.
Method of testing was to put a breakpoint on lines with a print, and then check if execution paused before text showed up in the Debug Console.
Of the 5 breakpoints only the first worked:
Thank You
Warm Regards
As the awaiting info tag is still there, should I be trying to supply more information somehow? I tried my best to make the project I shared previously to be as small as possible while still retaining both, my specific use case as well as the breakpoint issue.
Thank You
No, the repro is great! The label is removed by me when I process the issues from the notifications, though I was busy yesterday and didn't get through them all.
I can reproduce with your sample, though this seems to be an issue in DWDS (the debugging service used for web), so I've filed an issue at https://github.com/dart-lang/webdev/issues/1271 with a link to the repro steps back here.
I'll close this issue here as there should be nothing to do here - if the issue is fixed in DWDS, it'll be rolled into Flutter and arrive in a Flutter SDK update. Thanks!
...though this seems to be an issue in DWDS (the debugging service used for web), so I've filed an issue at dart-lang/webdev#1271 with a link to the repro steps back here.
I know you must be extremely busy, but if convenient to explain, how did you come to that conclusion given the log you've put on that issue?
Thank you for the help.
The way the debugging works in VS Code is that we have a "debug adapter" that translates messages from VS Code's debugger into messages for the Dart VM/runtime. So when VS Code says "add a breakpoint at this line", all the debug adapter does is translate that into an equivalent message for the VM.
In the case of Web, there is no real Dart VM, so there's a project called "DWDS" that's part of the webdev package, which emulates the Dart VM (or rather, its debugger API - known as "the VM Service") and translates those messages into Chrome debugger API messages (this translation is much more complicated then the one the Dart-Code debug adapter does).
The log file shows that when the Dart-Code debug adapter sent "addBreakpoint" messages to the DWDS service, they failed with an error (which I've included below, reformatted slightly so it's easier to see).
Since the intention is that DWDS is compatible with the VM (so that Dart-Code and other IDEs only need to implement a single debug adapter for both web+non-web without needing to handle differences), it's something that should _probably_ be fixed in DWDS.
If it turns out to be difficult to fix there or VS Code is doing something unexpected (that just happens to work in the real VM) it may be convenient to fix here, but I can discuss that with the dwds devs if that happens to be the case.
fwiw, I frequently communicate with devs on the Dart teams - this wasn't a case of throwing it over the fence, but rather moving it to the tracker where it's most likely to be looked at efficiently 馃檪 . I'll get notifications of comments on that issue, and will continue to follow up to help debug if required.
Hope this makes sense!
{
"jsonrpc": "2.0",
"id": "13",
"error": {
"code": -32603,
"message": "addBreakpointWithScriptUri: Invalid argument (uri): Unknown library: \"file:///private/tmp/_brokenBreakpoints/lib/trying.dart\"",
"data": {
"details": "
#0 new DartUri._fromFileUri (package:dwds/src/utilities/dart_uri.dart:144:5)
#1 new DartUri (package:dwds/src/utilities/dart_uri.dart:114:49)
#2 ChromeProxyService.addBreakpointWithScriptUri (package:dwds/src/services/chrome_proxy_service.dart:304:19)
#3 VmServerConnection._delegateRequest (package:vm_service/src/vm_service.dart:1260:51)
#4 _rootRunUnary (dart:async/zone.dart:1362:47)
#5 _CustomZone.runUnary (dart:async/zone.dart:1265:19)
#6 _CustomZone.runUnaryGuarded (dart:async/zone.dart:1170:7)
#7 _BufferingStreamSubscription._sendData (dart:async/stream_impl.dart:341:11)
#8 _BufferingStreamSubscription._add (dart:async/stream_impl.dart:271:7)
#9 _ForwardingStreamSubscription._add (dart:async/stream_pipe.dart:123:11)
#10 _MapStream._handleData (dart:async/stream_pipe.dart:218:10)
#11 _ForwardingStreamSubscription._handleData (dart:async/stream_pipe.dart:153:13)
#12 _rootRunUnary (dart:async/zone.dart:1362:47)
#13 _CustomZone.runUnary (dart:async/zone.dart:1265:19)
#14 _CustomZone.runUnaryGuarded (dart:async/zone.dart:1170:7)
#15 _BufferingStreamSubscription._sendData (dart:async/stream_impl.dart:341:11)
#16 _BufferingStreamSubscription._add (dart:async/stream_impl.dart:271:7)
#17 _SyncStreamControllerDispatch._sendData (dart:async/stream_controller.dart:733:19)
#18 _StreamController._add (dart:async/stream_controller.dart:607:7)
#19 _StreamController.add (dart:async/stream_controller.dart:554:5)
#20 new WebSocketImpl.fromSocket.<anonymous closure> (package:web_socket_channel/src/copy/web_socket_impl.dart:728:21)
#21 _rootRunUnary (dart:async/zone.dart:1362:47)
#22 _CustomZone.runUnary (dart:async/zone.dart:1265:19)
#23 _CustomZone.runUnaryGuarded (dart:async/zone.dart:1170:7)
#24 _BufferingStreamSubscription._sendData (dart:async/stream_impl.dart:341:11)
#25 _BufferingStreamSubscription._add (dart:async/stream_impl.dart:271:7)
#26 _SinkTransformerStreamSubscription._add (dart:async/stream_transformers.dart:63:11)
#27 _EventSinkWrapper.add (dart:async/stream_transformers.dart:13:11)
#28 _WebSocketProtocolTransformer._messageFrameEnd (package:web_socket_channel/src/copy/web_socket_impl.dart:320:22)
#29 _WebSocketProtocolTransformer.add (package:web_socket_channel/src/copy/web_socket_impl.dart:219:46)
#30 _SinkTransformerStreamSubscription._handleData (dart:async/stream_transformers.dart:111:24)
#31 _rootRunUnary (dart:async/zone.dart:1362:47)
#32 _CustomZone.runUnary (dart:async/zone.dart:1265:19)
#33 _CustomZone.runUnaryGuarded (dart:async/zone.dart:1170:7)
#34 _BufferingStreamSubscription._sendData (dart:async/stream_impl.dart:341:11)
#35 _BufferingStreamSubscription._add (dart:async/stream_impl.dart:271:7)
#36 _SyncStreamControllerDispatch._sendData (dart:async/stream_controller.dart:733:19)
#37 _StreamController._add (dart:async/stream_controller.dart:607:7)
#38 _StreamController.add (dart:async/stream_controller.dart:554:5)
#39 _Socket._onData (dart:io-patch/socket_patch.dart:2144:41)
#40 _rootRunUnary (dart:async/zone.dart:1370:13)
#41 _CustomZone.runUnary (dart:async/zone.dart:1265:19)
#42 _CustomZone.runUnaryGuarded (dart:async/zone.dart:1170:7)
#43 _BufferingStreamSubscription._sendData (dart:async/stream_impl.dart:341:11)
#44 _BufferingStreamSubscription._add (dart:async/stream_impl.dart:271:7)
#45 _SyncStreamControllerDispatch._sendData (dart:async/stream_controller.dart:733:19)
#46 _StreamController._add (dart:async/stream_controller.dart:607:7)
#47 _StreamController.add (dart:async/stream_controller.dart:554:5)
#48 new _RawSocket.<anonymous closure> (dart:io-patch/socket_patch.dart:1680:33)
#49 _NativeSocket.issueReadEvent.issue (dart:io-patch/socket_patch.dart:1192:14)
#50 _microtaskLoop (dart:async/schedule_microtask.dart:40:21)
#51 _startMicrotaskLoop (dart:async/schedule_microtask.dart:49:5)
#52 _runPendingImmediateCallback (dart:isolate-patch/isolate_patch.dart:120:13)
#53 _RawReceivePortImpl._handleMessage (dart:isolate-patch/isolate_patch.dart:185:5)
"
}
}
}
Yes, it very much does! Thank you yet again for being so nice.
It also explains why programmatic breakpoints are working fine.
Most helpful comment
The way the debugging works in VS Code is that we have a "debug adapter" that translates messages from VS Code's debugger into messages for the Dart VM/runtime. So when VS Code says "add a breakpoint at this line", all the debug adapter does is translate that into an equivalent message for the VM.
In the case of Web, there is no real Dart VM, so there's a project called "DWDS" that's part of the webdev package, which emulates the Dart VM (or rather, its debugger API - known as "the VM Service") and translates those messages into Chrome debugger API messages (this translation is much more complicated then the one the Dart-Code debug adapter does).
The log file shows that when the Dart-Code debug adapter sent "addBreakpoint" messages to the DWDS service, they failed with an error (which I've included below, reformatted slightly so it's easier to see).
Since the intention is that DWDS is compatible with the VM (so that Dart-Code and other IDEs only need to implement a single debug adapter for both web+non-web without needing to handle differences), it's something that should _probably_ be fixed in DWDS.
If it turns out to be difficult to fix there or VS Code is doing something unexpected (that just happens to work in the real VM) it may be convenient to fix here, but I can discuss that with the dwds devs if that happens to be the case.
fwiw, I frequently communicate with devs on the Dart teams - this wasn't a case of throwing it over the fence, but rather moving it to the tracker where it's most likely to be looked at efficiently 馃檪 . I'll get notifications of comments on that issue, and will continue to follow up to help debug if required.
Hope this makes sense!