Skip to content

Support debugging in IntelliJ #459

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
3 tasks
nex3 opened this issue Sep 1, 2016 · 14 comments
Closed
3 tasks

Support debugging in IntelliJ #459

nex3 opened this issue Sep 1, 2016 · 14 comments
Labels
customer-bolt2 IDE integration type-enhancement A request for a change that isn't a bug

Comments

@nex3
Copy link
Member

nex3 commented Sep 1, 2016

Based on my conversation with @jwren, @devoncarew, and @kevmoo here are the components of debugging support we need:

  • Emitting debugging information in JSON format when using the JSON reporter. The information here should include the Chrome remote debugger URL (when running Chrome, Dartium or content shell) and/or the Observatory URL (when running Dartium, content shell, or eventually the VM).
  • Providing a means to control the test runner using the remote debugger protocol. Specifically, the IDE needs to be able to have the sorts of control a user would from the command line. This currently includes the ability to continue a test suite after connecting to the debugger and setting breakpoints, and the ability to restart a test on command. We should be able to expose public JS APIs for these in the host frame using JS interop.
  • Add support for determining the remote debugger URL for Firefox.

IntelliJ folks: do you have the means to interact with with Firefox, Safari, or IE's remote debuggers? Right now we only have logic for extracting information from Chrome- and Dartium-alikes, but if it's possible to do so for other browsers and it would be useful, we can expand that.

@nex3 nex3 added type-enhancement A request for a change that isn't a bug IDE integration labels Sep 1, 2016
@devoncarew
Copy link
Member

/cc @stevemessick

@alexander-doroshko
Copy link

IntelliJ folks: do you have the means to interact with with Firefox, Safari, or IE's remote debuggers?

IntelliJ IDEA supports debugging in Firefox. I never tried and didn't look in the related code, but I suppose the answer is 'yes' for Firefox. Safari and IE - No.

@vpigrad
Copy link

vpigrad commented Sep 2, 2016

I haven't been able to get debugging to work in Firefox. Tried dozens of times and so have several coworkers. Debugging in Dartium works about a tenth of the time.

@nex3
Copy link
Member Author

nex3 commented Sep 27, 2016

@alexander-doroshko I've added a task for finding the remote debugger URL for Firefox.

@vpigrad I expect the IntelliJ team would be very interested in hearing your bug reports, but I don't think this is the place. Alexander, where can they follow up to send y'all more information?

@alexander-doroshko
Copy link

@vpigrad Debugging Dart in Firefox has never been tested, not sure it ever worked. Debugging should work in Chromium-based browsers. Issue tracker link: https://youtrack.jetbrains.com/issues/Web, subsytem: Dart.

@nex3 Firefox-related part is low priority.
BTW what do you think about dart-lang/pub#1204 (comment)? It may give IDE another way to debug VM-based tests.

@jwren
Copy link
Member

jwren commented Sep 27, 2016

@devoncarew who has been working on some of the debugger source in IJ

@nex3
Copy link
Member Author

nex3 commented Sep 28, 2016

BTW what do you think about dart-lang/pub#1204 (comment)? It may give IDE another way to debug VM-based tests.

That's not a good way to debug VM tests. Debugging should only be done through the explicit interface provided by the test runner.

At some point, I'm going to reimplement pub run so that it runs its child "process" in an isolate rather than an actual subprocess, so passing VM flags isn't an API we can support.

@alexander-doroshko
Copy link

I'm going to reimplement pub run so that it runs its child "process" in an isolate rather than an actual subprocess, so passing VM flags isn't an API we can support.

That's exactly what dart-lang/pub#1204 is about. As soon as dart-lang/pub#1204 is done users will be able to debug any app started via pub run using documented way:

[Dart SDK]/bin/dart --pause_isolates_on_start --enable-vm-service:50412 [Dart SDK]/bin/snapshots/pub.dart.snapshot run whatever.dart.app

Of course I'm also happy with debugging using explicit interface provided by the test runner, and this approach has certain advantages.

@nex3
Copy link
Member Author

nex3 commented Sep 28, 2016

That's exactly what dart-lang/pub#1204 is about. As soon as dart-lang/pub#1204 is done users will be able to debug any app started via pub run using documented way:

[Dart SDK]/bin/dart --pause_isolates_on_start --enable-vm-service:50412 [Dart SDK]/bin/snapshots/pub.dart.snapshot run whatever.dart.app

This is not officially supported either; you should only ever invoke pub by running the wrapper script. In fact, I'd say that invoking the snapshot is likely to break once dart-lang/sdk#24736 is fixed.

@devoncarew
Copy link
Member

Looking at that list above, I'm not sure Firefox is a priority; being able to debug VM tests would be higher on my list. I'd also de-prioritize Dartium, and add debugging of Flutter tests (which are also service-protocol based).

Given that we have a full featured command-line debugger, the work to debug VM tests should be pretty tractable. Hereabouts: https://github.com/flutter/flutter/blob/master/packages/flutter_tools/lib/src/test/flutter_platform.dart#L170, flutter is able to run tests, open a service protocol port, and connect to it for the purposes of grabbing coverage data. We should be able to use a similar technique to connect, set breakpoints, and debug.

@nex3
Copy link
Member Author

nex3 commented Sep 28, 2016

@devoncarew I'm not worried about Firefox being difficult to support. I agree that VM debugging is important, but it's blocked; see #50. Flutter support isn't part of the core test package; they maintain a separate plugin. If their plugin emits an Environment with observatoryUrl set, it should seamlessly work with any debugging infrastructure I add.

@devoncarew
Copy link
Member

OK, test may not be the right forum, but from an IntelliJ perspective, our priority is to be able to debug VM and Flutter tests from IntelliJ. I don't think that work is blocked by #50, given that flutter_tools is able to execute tests and connect to a service protocol port. It would probably be worth having a higher bandwidth conversation about it, so I can better understand your design and concerns.

@nex3
Copy link
Member Author

nex3 commented Sep 28, 2016

Feel free to put something on my calendar, preferably in the afternoon.

@TimIrwin26
Copy link

If I can chime in for a moment as a user (and proponent) of Dart and
IntelliJ, I can say that my life would be made much, much easier by
integrated (including debugging) browser based unit tests in IntelliJ.
Dartium is fine, more browsers would be appreciated, but please at least
have something.

Thanks,
Tim Irwin
Software Architect, Ascentis

On 9/28/16 1:21 PM, Devon Carew wrote:

OK, |test| may not be the right forum, but from an IntelliJ
perspective, our priority is to be able to debug VM and Flutter tests
from IntelliJ. I don't think that work is blocked by #50
#50, given that
flutter_tools is able to execute tests and connect to a service
protocol port. It would probably be worth having a higher bandwidth
conversation about it, so I can better understand your design and
concerns.


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#459 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AD-uF0DTCO3IdjguYlDZjaGlfHyEEx5Eks5qusxIgaJpZM4JzENI.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
customer-bolt2 IDE integration type-enhancement A request for a change that isn't a bug
Projects
None yet
Development

No branches or pull requests

7 participants