1165010 - Set a breakpoint for errors in WebConsole (like Firebug)

Status: NEW

(DevTools :: Console, enhancement, P3)

Description

[Florent Fayolle]

Attachment: firebug_console_breakpoint.gif

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0
Build ID: 20150508094354

Steps to reproduce:

Firebug 2.0 has a feature that allows setting a breakpoint in its Console for the errors.

Use case:
1. Open the devtools on this page: http://localhost/firebug/console/5216/issue5216.html
2. Click on the "Cause Exception" button
3. In the WebConsole, you see an error. With this error, you should be able to set a breakpoint which will break where the error occurred.

Also see the attached gif to see how Firebug handles that.

Florent

Comment 1

[Florent Fayolle]

Sorry, the pace of the frames of the gif is fast...

Florent

Comment 2

[Lin Clark [:linclark]]

:odvarko, do you know if there are plans to implement this?

Comment 3

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

(In reply to Lin Clark [:linclark] from comment #2)
> :odvarko, do you know if there are plans to implement this?

I don't know about any plans, but I like that feature
and the way how it's implemented in Firebug.

You might also see this demo page (demoing various kind of breakpoints):
https://getfirebug.com/doc/breakpoints/demo.html#errors

UI/UX:
- see the gray circle displayed before the source-code-line (the one where the error happened)
- it indicates a place where you can create a breakpoint by clicking

Helen, what do you think about the UI/UX?

Honza

Comment 4

[Helen V. Holmes (:helenvholmes) (:✨)]

(In reply to Jan Honza Odvarko [:Honza] from comment #3)
> UI/UX:
> - see the gray circle displayed before the source-code-line (the one where
> the error happened)
> - it indicates a place where you can create a breakpoint by clicking

I like the UX! The only question is a UI one—should we have the circle be red because it's an error, or blue because debugger breakpoints are traditionally blue?

I don't know the right answer—that's the question I would ask for this bug, though.

Comment 5

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

(In reply to Helen V. Holmes (:helenvholmes) (:✨)(Please needinfo) from comment #4)
> I like the UX! The only question is a UI one—should we have the circle be
> red because it's an error, or blue because debugger breakpoints are
> traditionally blue?
> I don't know the right answer—that's the question I would ask for this bug,
> though.

I think that the breakpoint itself should look exactly the same as it looks like in the debugger panel so, it's consistent across the entire UI (which also means we should use the new marker). This allows the user to quickly understand that a breakpoint has been created (after clicking).
It's up to the log itself to be visually designed so, it's clear that it's an error.

Note that fixing this would make Firebug users a bit happier when switching to DevTools.

Honza

Comment 6

[Sebastian Zartner [:sebo]]

For what it's worth, I want to note that users can also stop the script execution on all errors by activating the "Pause on all exceptions" button within the Debugger. Having said that, users should still be able to stop at individual exceptions.

Question is, how both options should interact. There are two ways I can imagine:

1. If "Pause on all exceptions" is activated, the script execution is always paused on an uncaught error, i.e. it stops independently of whether breakpoints are set for individual errors. (The display of the error breakpoints within the console might even be hidden in this case.)
2. If "Pause on all exceptions" is activated, all error breakpoints are activated by default, though users can deactivate individual breakpoints within the console. I.e. it toggles the logic from a whitelist ("only these errors should break") to a blacklist ("all errors except these should break").

I slightly prefer the second option, because it makes it more obvious when the script execution halts and it is more flexible, as it allows to ignore specific exceptions. Though, in that case, the Debugger needs to make it obvious that those errors are ignored and provide a way to toggle them.

Sebastian