966198 - Allow breakpoints to resume automatically and play sounds

Status: NEW

(DevTools :: Debugger, enhancement, P3)

Description

[Panos Astithas (he/him) [:past] (please ni?)]

Attachment: Initial proof of concept

Here is a patch that enhances our breakpoints with two new abilities: (1) to resume automatically without UI distractions and (2) to play a sound when triggered. These two options when combined provide the ability to identify a code path taken in a lightweight way, without having to pause and inspect the program state. Here is a video of it in action: https://vimeo.com/85442073

Some use cases where this can be useful are:
- verifying whether some number of events are triggered during a complex user interaction and if their order is correct
- making sure that addEventListener calls are matched with removeEventListener ones (or similar, potentially-leaky code paths), possibly combined with a condition that verifies event type or origin
- asserting conditions at various points without having to pause execution, but while still getting an audible feedback
- making the debugger more accessible to the visually impaired
- creating music works by elaborately placing breakpoints in JavaScript programs (OK, maybe not this last one)

In this version I have experimented with providing simple notes, instead of full sound files in order to avoid increasing the download size, but also to minimize work (creating adequate sound files is a different ball game, although I could probably just use the Firefox OS alerts). It may turn out that identifying different notes is not easy for the less musically adept and more rich sounds are necessary. One other option is to use chords instead of simple notes and another one is to use different sound waves (e.g. using a sawtooth oscillator sounds more like a string than a synth).

Breakpoints could be expanded to provide hooks for arbitrary script execution, or even launch programs or shell commands from the OS, but I don't see much value in doing that. It also starts to become a very complicated ordeal, far from the kind of tool one tends to use while debugging.

Another direction could be to extend these non-pausing notifications to use visual cues as well, to cater to the hearing impaired. Flashing the breakpoint summary in the source list might be one idea, adding a transient label or badge is another one.

Displaying a count of the times a breakpoint was hit is an additional idea, although I don't see it being very useful in practice. It will also bring the requirement to have an affordance to reset the counter.

Lastly, I would like to mention that this is a feature that none of our competitors have (I've only heard of XCode having something like this, but never used it myself) and could be interesting from a differentiating angle too. I'd like to get more feedback after folks play with it for a bit. Try builds for all platforms can be found here:

http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-03e5f82d0e2d/

Comment 1

[Patrick Brosset <:pbro>]

I really like the idea of auto-resuming breakpoints, and the sound idea is pretty unique too. I'd need to experiment a bit with it to judge its usefulness.

In any case, I've used many times in the past the ability to use auto-resuming breakpoints by using conditional breakpoints that evaluate to false.
This is very useful when debugging something on a production platform say, where you can't change the source code.
Doing this basically give you the ability to inject code in the running app/site and any point you want.

This is particularly useful to log things out, or change values of variables and test a fix for instance.

So, I'm totally for having an option to not stop execution.

I'm also going to file a separate bug for having a larger input field in the conditional breakpoints.
If the input could feel more like scratchpad for instance, then this + auto-resuming option would make for an awesome way to inject code.

Comment 2

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

Ship it!

http://images.cheezburger.com/completestore/2011/11/2/aa83c0c4-2123-4bd3-8097-966c9461b30c.jpg

Comment 3

[Brian Grinstead [:bgrins]]

(In reply to Patrick Brosset [:pbrosset] [:patrick] from comment #1)
> I really like the idea of auto-resuming breakpoints, and the sound idea is
> pretty unique too. I'd need to experiment a bit with it to judge its
> usefulness.
> 
> In any case, I've used many times in the past the ability to use
> auto-resuming breakpoints by using conditional breakpoints that evaluate to
> false.
> This is very useful when debugging something on a production platform say,
> where you can't change the source code.
> Doing this basically give you the ability to inject code in the running
> app/site and any point you want.
> 
> This is particularly useful to log things out, or change values of variables
> and test a fix for instance.
> 
> So, I'm totally for having an option to not stop execution.
> 
> I'm also going to file a separate bug for having a larger input field in the
> conditional breakpoints.
> If the input could feel more like scratchpad for instance, then this +
> auto-resuming option would make for an awesome way to inject code.

Having a breakpoint that doesn't stop execution is interesting to me for pretty much the same reason that Patrick outlines.  Sometimes I want to log out a value, but don't want to pause execution every time it happens (for instance, if this is a callback happening on a mouse move).  The conditional breakpoint with executable code that returns false is a clever way to accomplish this, but it's very much a hack and it would be nice to have a UI intended for this.

Comment 4

[Axel Kratel]

This is a brilliant feature, I see two very significant use cases for this. 

1) Auto-resume break points could be useful in both performance management and automated testing. 

- we will need these for setting "bookmarks" that can be seen on the perf tools
- these breakpoints could be used to trigger heap snapshots at desired points in time
- during automated perf tests, the break points could be used to log specific performance data of interest such as for example memory or jank. 

2) Sound feedback is tremendously useful for game development where you need to keep your eyes on the game graphics but could benefit from additional auditory feedback on program execution. 

So I vote to ship this. This is a very cool feature on top of which we can add lots of very basic functionality.

Comment 5

[Panos Astithas (he/him) [:past] (please ni?)]

A few more ideas about cases where sound breakpoints could be useful:
- identify whether clearInterval or clearTimeout were called
- a "click" or any other event was handled once or multiple times
- breakpoints on constructors: identify whether an object was reused or another instance was created

Another potential feature unrelated to sound would be the option to ignore the first N occurrences of the breakpoint, even though that's not something I expect to be widely used. Perhaps inside for..in loops, or when for..of becomes mainstream.

Comment 6

[Panos Astithas (he/him) [:past] (please ni?)]

Another useful breakpoint optional action: log a stack trace (console, maybe even file), so that I can verify the code paths that led to this point at runtime.

Comment 7

[Panos Astithas (he/him) [:past] (please ni?)]

It's not likely that I'll be working on this any time soon.