Source Editor should provide an API for disabling, but not removing, a breakpoint

NEW
Unassigned

Status

()

Firefox
Developer Tools: Source Editor
P2
normal
6 years ago
4 years ago

People

(Reporter: past, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sourceeditor])

One common user interaction with breakpoints is to disable them temporarily, without removing them altogether. In that case the behavior is the same for the debugger as removing the breakpoint, but the editor should display a different, more subtle indicator in the same place (hollow or translucent icon, for instance). We need to expose an editor.disableBreakpoint/enableBreakpoint sort of API to implement that in the debugger.

Updated

6 years ago
Priority: -- → P2
Whiteboard: [sourceeditor]

Updated

6 years ago
Assignee: nobody → mihai.sucan
Status: NEW → ASSIGNED
Depends on: 759351
Moving to Source Editor component.

Filter on CHELICERAE.
Component: Developer Tools → Developer Tools: Source Editor
(not actively working on source editor bugs)
Assignee: mihai.sucan → nobody
Status: ASSIGNED → NEW
Is there a feature that needs this? If not, I'd rather close this bug and file a new one when needed.
Flags: needinfo?(past)
(Reporter)

Comment 4

4 years ago
Yes, disabled (but not removed) breakpoints in the UI is a feature supported by most (all?) of the competition, like Chrome and Firebug.
Flags: needinfo?(past)
Sorry I'll re-phrase. Do we have a feature bug for this in the Debugger component that someone will actively work on *soon*? APIs that just sit there without anyone using are not a good thing, IMHO.
I think the implementation here would (or should) pretty much coincide with changes in the debugger frontend. This is really not much harder than simply applying different styling for the breakpoint icons in the gutter.
(Reporter)

Comment 7

4 years ago
What Victor said, but I can file a separate bug for the debugger frontend changes if you prefer. This is such a tailored API/feature that I would expect both parts to be developed together to verify the suitability of the API to the consumer.

As for how soon this work will happen, well, we are not planning to work on *any* debugger bugs in the near future with the upcoming shift to perf tools. Of course that doesn't mean we should close all of the logged bugs for further feature work.
No longer depends on: 759351
You need to log in before you can comment on or make changes to this bug.