1441183 - Resume lands on the same location

Status: RESOLVED FIXED

(DevTools :: Debugger, defect, P2)

Description

[Jason Laster [:jlast]]

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

Comment 1

[Jan Honza Odvarko [:Honza] (always need-info? me)]

(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

Comment 3

[Jason Laster [:jlast]]

Another use-case is

1. step to a breakpoint
2. press resume

bug 1417240

Comment 5

[Logan Smyth [:loganfsmyth]]

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.

Comment 6

[Jason Laster [:jlast]]

Attachment: Bug 1441183 - Resume lands on the same location. r=loganfsmyth

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/b9502b7c8ea2
Resume lands on the same location. r=loganfsmyth

Comment 8

[Stefan Hindli [:stefan_hindli]]

https://hg.mozilla.org/mozilla-central/rev/b9502b7c8ea2