In Firefox I can do, from my long-running JavaScript program (running in a tab with no dev tools open):
alert("while this alert is still on, open Dev Tools (Shift-Ctrl-I) to hit a breakpoint as soon as you hit ok");
debugger;
and it works as expected, i.e. if I manually open the dev tools while the alert window is still open, the program then pauses in the debugger as soon as I close the alert.
In Chrome this does not work. I tried eval('debugger') instead of just debugger, but that does not work either. Is there any alternative for Chrome? Perhaps in the form of an extension (as long as it has no runtime overhead).
Running the program with Dev Tools open from the start is not an option, as it has a big impact on performance (the program is two to three times slower), so I want to be able to switch back and forth (when I am done debugging, I want to resume and close the Dev Tools - ideally the debugging session should also allow edit and continue, but that's another can of worms).
Essentially what I need is a zero-overhead breakpoint for Chrome
This is not a general solution to the question that I asked, but it works for my particular case, so I am sharing it here. On one hand it illuminates a little the mechanics of why it does not work in Chrome as-is, on the other hand it might help others that also run code within generators.
While attempting to see if a second alert might help, I noticed that, although I had started the Dev Tools during the first alert, the sources pane was still blank when the page was stopped during the second alert. This made me think that control had not returned to the browser, therefore the source (more precisely the dev tools debugger) was still not active, not until the current evaluation had run its course, and that's why the debugger statement was ignored. I tested that hypothesis, and indeed, using
alert("while this alert is still on, open Dev Tools (Shift-Ctrl-I) to hit a breakpoint as soon as you hit ok");
setTimeout(function run () {
debugger;
});
I got Chrome to pause in the debugger as well. Of course, the pause does not actually happen right away, it only happens after the fact (after the last statement in the script), asynchronously with the script execution, but for me this is good enough, given that my code runs inside generators - the program's main run loop looks something like:
setTimeout(function run () {
generator.next();
setTimeout(run);
});
So in the places where I want to switch to debug mode, I can simply do:
alert("while this alert is still on, open Dev Tools (Shift-Ctrl-I) to hit a breakpoint as soon as you hit ok");
yield;
debugger;
Given that an interruption in the program follows anyway, the fact that the program does an extra yield to the browser/call to setTimeout is irrelevant, and when the program does eventually (within the following next() generator invocation) stop in the debugger, it is in the correct (synchronous) state.