Closed Bug 1441183 Opened 2 years ago Closed 3 months ago

Resume lands on the same location

Categories

(DevTools :: Debugger, defect, P2)

defect

Tracking

(firefox69 fixed)

RESOLVED FIXED
Firefox 69
Tracking Status
firefox69 --- fixed

People

(Reporter: jlast, Assigned: jlast)

References

(Blocks 2 open bugs)

Details

(Whiteboard: [debugger-mvp])

Attachments

(1 file)

When the user steps over a line, the server will guarantee that the debugger pauses on a new line. This is not the case for resuming.

2 cases where this does not hold up are

1. adding a breakpoint at a debugger statement
2. adding a breakpoint at a multiline call expression

Here is a STR
1. go to https://dbg-two-step.glitch.me/
2. go to client.js and add a breakpoint on line 48 and 49
3. click simple button
4. pause, resume, resume

ER: land on debugger statement, pause on foo, resume
AR: land on debugger statements twice, pause on foo twice
Blocks: js-devtools
Priority: -- → P2
Product: Firefox → DevTools
Blocks: dbg-stepping
Blocks: dbg-control
No longer blocks: dbg-stepping
Blocks: dbg-68

(In reply to Jason Laster [:jlast] from comment #0)

  1. go to https://dbg-two-step.glitch.me/
  2. go to client.js and add a breakpoint on line 48 and 49
  3. click simple button
  4. pause, resume, resume

ER: land on debugger statement, pause on foo, resume
AR: land on debugger statements twice, pause on foo twice

I followed this STRs and for me the debugger pauses:

  • twice at the debugger keyword
  • just once at foo

Honza

Duplicate of this bug: 1171174

Another use-case is

  1. step to a breakpoint
  2. press resume

bug 1417240

Duplicate of this bug: 1417240
Whiteboard: [debugger-mvp]

The core issue here is that stepping currently performs this check: https://searchfox.org/mozilla-central/source/devtools/server/actors/thread.js#680 but onDebuggerStatement runs after that and has no such check, so if you step to a debugger statement, you're actually paused just before it runs, and then if you try to step again, the onDebuggerStatement hooks runs and we pause there too. We'd need to consistently keep track of either our most recent position, or our most recent paused frame.offset value. Personally I'd love for that to be based on frame.offset so if someone wanted to do that as part of this work I'd support it, but I also understand if just preserving the same logic we have for if (!lineChanged && !columnChanged) { is easier.

The same is true for breakpoint hit. Breakpoints run after onStep handlers, so you'll pause once at the step handler, and then resuming/stepping again will hit the breakpoint and pause again.

Assignee: nobody → jlaster
Status: NEW → ASSIGNED
Pushed by jlaster@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/b9502b7c8ea2
Resume lands on the same location. r=loganfsmyth
Status: ASSIGNED → RESOLVED
Closed: 3 months ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 69
You need to log in before you can comment on or make changes to this bug.