1171174 - Resuming debugger execution takes two clicks

Status: RESOLVED DUPLICATE of bug 1441183

(DevTools :: Debugger, defect)

Description

[Jonathan Allard]

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.

Comment 1

[Jonathan Allard]

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?

Comment 2

[Tom Tromey :tromey]

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.

Comment 3

[Tom Tromey :tromey]

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.

Comment 4

[Jason Laster [:jlast]]

I believe this is a dupe of bug 1441183