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.
(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.
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.
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.
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.
It's not likely that I'll be working on this any time soon.