User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:40.0) Gecko/20100101 Firefox/40.0 Build ID: 20150602004005 Steps to reproduce: Given running in safe mode 1. Go to http://todomvc.com/examples/backbone/ 2. Open debugger, place breakpoint on first executed line (line 11) 3. Reload page 4. Click Resume execution Actual results: Debugger stands stopped, Resume arrow still visible, needs to be clicked a second time for execution to resume. Expected results: Debugger resumes.

Similar to 1123380, apparently closed due to bad add-ons. I don't know how to say this, but it feels like I'm getting bug after bug for the ~year I've switched over to devtools. How can that be?

I think the issue here is that the line in question has two entry points, but one of the entry points is a bit odd. Then according to this theory, what happens is that the debugger sets breakpoints at both entry points. The first such breakpoint is hit on reload; then after continuing, the second breakpoint is hit -- but as it is on the same line, nothing appears to happen. Here's a test case showing the bug: var global = newGlobal(); Debugger(global).onDebuggerStatement = function (frame) { var script = frame.eval("f").return.script; print(JSON.stringify(script.getAllOffsets())); }; fstr = `function f() { zzz = something({ a: 57, b: whatever() }); } debugger;`; global.log = ''; global.eval(fstr); eval(fstr) dis(f) When I run it: pokyo. ./obj-x86_64-unknown-linux-gnu/dist/bin/js /tmp/r.js [null,null,[0,45],[20],[27],[54]] flags: CONSTRUCTOR loc op ----- -- main: 00000: bindname "zzz" 00005: getname "something" 00010: gimplicitthis "something" 00015: newobject ({a:(void 0), b:(void 0)}) 00020: int8 57 00022: initprop "a" 00027: getname "whatever" 00032: gimplicitthis "whatever" 00037: call 0 00040: initprop "b" 00045: call 1 00048: setname "zzz" 00053: pop 00054: retrval Source notes: ofs line pc delta desc args ---- ---- ----- ------ -------- ------ 0: 1 0 [ 0] newline 1: 2 0 [ 0] colspan 4 3: 2 20 [ 20] xdelta 4: 2 20 [ 0] newline 5: 3 20 [ 0] colspan 1 7: 3 27 [ 7] newline 8: 4 27 [ 0] colspan 1 10: 4 37 [ 10] xdelta 11: 4 37 [ 0] colspan 3 13: 4 45 [ 8] xdelta 14: 4 45 [ 0] setline lineno 2 16: 2 45 [ 0] colspan 10 18: 2 54 [ 9] xdelta 19: 2 54 [ 0] setline lineno 5 21: 5 54 [ 0] colspan 7 The entry points in question are at PC=0 and PC=45. This is related to bug 1003554 and its dependencies, though here it isn't clear to me what can be done about it.

Nick suggested that one way would be to provide some feedback so users know that something is happening -- like some kind of fade-out animation on the breakpoint icon when continuing and another animation when stopping. The usual approach to bugs like this is to change the source notes so that some instructions are skipped by the debugger (see bug 1003554 et al). But I think that won't work in this situation -- it would regress other scenarios. We also discussed the idea of a heuristic in the debugger, like "if continuing from a breakpoint location, and the next stop is on the same line and frame, don't stop". Our current thinking though is that heuristics like this are difficult to get correct; for instance this variant fails for some kinds of loops, where you would want to stop at each iteration.