Set a breakpoint for errors in WebConsole (like Firebug)

NEW
Unassigned

Status

()

Firefox
Developer Tools: Console
P3
enhancement
2 years ago
4 months ago

People

(Reporter: Florent Fayolle, Unassigned)

Tracking

(Blocks: 1 bug)

41 Branch
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

2 years ago
Created attachment 8605971 [details]
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
(Reporter)

Updated

2 years ago
Blocks: 991806
Component: Untriaged → Developer Tools: Console
(Reporter)

Comment 1

2 years ago
Sorry, the pace of the frames of the gif is fast...

Florent
:odvarko, do you know if there are plans to implement this?
Flags: needinfo?(odvarko)
(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
Flags: needinfo?(odvarko) → needinfo?(hholmes)
(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.
Flags: needinfo?(hholmes) → needinfo?(odvarko)
(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
Flags: needinfo?(odvarko)
See Also: → bug 1004678
See Also: → bug 895893
See Also: → bug 1267144
See Also: → bug 821610
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
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.