The plugin already support support the openSourceLocation service.
Adding another service called 'openFrame' observatory can ask the editor to show a specific frame.
An example is the dominator tree, were the bottleneck is a frame itself and right now cannot be analyzed.
Update:
During heap analysis we can potentially encounter objects that are kept alive just by Stack Frames.
In this case we do not have a source location associated with the frame, so we cannot send the use back to the editor.
A possible solution would be to send the user to the debugger and select the blamed stack frame.
It is probably not useful for Flutter, where the stack clears every frame, but for normal Dart VM applications or background isolates can helpful.
The plugin already support support the
openSourceLocation
service. Adding another service called 'openFrame' observatory can ask the editor to show a specific frame. An example is the dominator tree, were the bottleneck is a frame itself and right now cannot be analyzed.Update: During heap analysis we can potentially encounter objects that are kept alive just by Stack Frames. In this case we do not have a
source location
associated with the frame, so we cannot send the use back to the editor. A possible solution would be to send the user to the debugger and select the blamed stack frame.It is probably not useful for Flutter, where the stack clears every frame, but for normal Dart VM applications or background isolates can helpful.