Open Bug 834506 Opened 7 years ago Updated 7 months ago

We need step into callback button

Categories

(DevTools :: Debugger, enhancement, P5)

x86
macOS
enhancement

Tracking

(Not tracked)

People

(Reporter: irakli, Unassigned)

References

(Blocks 1 open bug)

Details

Quite frequently when debugging some code you end with something like

doThat(input, function(error, data) {
  // stuff I'm interested in
})

If debugger on the 1st line clicking "step into callback" button should
get you on 2nd line. Cause most likely `doThat` comes from library that
you don't know or care internals of.

Would be great if `step into callback` button was context sensitive and only appeared on lines where debugged line is a function call to which callback
is passed.
Can't you just set a breakpoint in the first line of the callback instead? In your example that would be the one with the comment.
(In reply to Panos Astithas [:past] from comment #1)
> Can't you just set a breakpoint in the first line of the callback instead?

Yes, you can. But adding the breakpoint takes quite some time. I've noticed this pattern often as well. Can we do something like "Add breakpoint for callback function" keyboard shortcut/button?
From a user point of view, which is using Browser Debugger a lot of times these day, I will say that stepping into the callback function does not even make any sense, as there is no guarantee that the function will be even called ever (for example in a case of event handlers)

(In reply to Julian Viereck from comment #2)
> (In reply to Panos Astithas [:past] from comment #1)
> > Can't you just set a breakpoint in the first line of the callback instead?
> 
> Yes, you can. But adding the breakpoint takes quite some time. I've noticed
> this pattern often as well. Can we do something like "Add breakpoint for
> callback function" keyboard shortcut/button?

Wouldn't hitting a three key combination equally time consuming than clicking on the next line (if not more) ?
(In reply to Girish Sharma [:Optimizer] from comment #3)
>
> From a user point of view, which is using Browser Debugger a lot of times
> these day, I will say that stepping into the callback function does not even
> make any sense, as there is no guarantee that the function will be even
> called ever (for example in a case of event handlers)

This is a good catch! If the result of the action is a shortcut for "add breakpoint to first line of callback and continue the debugger" the behavior well defined again. Not sure how to give this shortcut a good name.

> Wouldn't hitting a three key combination equally time consuming than
> clicking on the next line (if not more) ?

For my workflow, which uses keyboard shortcuts heavily, I imagine it is faster to press a keyboard shortcut then performing an action with the mouse.
(In reply to Julian Viereck from comment #4)
> For my workflow, which uses keyboard shortcuts heavily, I imagine it is
> faster to press a keyboard shortcut then performing an action with the mouse.

Press down (VK_DOWN) and hit the shortcut for creating breakpoint (CTRL + B) ? -- total three keypresses
(In reply to Julian Viereck from comment #4)
> 
> For my workflow, which uses keyboard shortcuts heavily, I imagine it is
> faster to press a keyboard shortcut then performing an action with the mouse.

Indeed. Pressing DOWN (note that there's no guarantee that the callback's first statement is on the next line), adding a breakpoint there (accel+B) and the resuming (F6) requires some piano skills.

It's certainly possible (and easy) to fix this in the frontend with just a little bit of reflect.jsm, but I'll only agree if you fine people can find a good keyboard shortcut (and name!) for such an action :)
requires some parser magic. Seems like a low-priority thing.
Priority: -- → P3
Component: Developer Tools: Debugger → Developer Tools: User Stories
Component: Developer Tools: User Stories → Developer Tools: Debugger
Product: Firefox → DevTools
Blocks: dbg-control
Type: defect → enhancement
Priority: P3 → P5
You need to log in before you can comment on or make changes to this bug.