Closed
Bug 1126193
Opened 10 years ago
Closed 10 years ago
setBreakpoint should not take a full location.
Categories
(DevTools :: Debugger, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
Firefox 38
People
(Reporter: ejpbruel, Assigned: ejpbruel)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
(deleted),
patch
|
fitzgen
:
review+
|
Details | Diff | Splinter Review |
setBreakpoint doesn't actually need to take a full location object as argument. Since setBreakpoint is a member of SourceActor, the sourceActor is already implicit. Being able to pass a different sourceActor via the location object is confusing, and a potential source of bugs.
In addition, I would like to remove column breakpoints from the protocol for the time being, since they aren't actually supported on the protocol level. We need them for setting breakpoints on source mapped sources, but that's an implementation detail. Even though we expose column breakpoints to the protocol, their semantics aren't clear at the moment.
Moreover, column breakpoints aren't actually supported by the UI right now, so the only places they are actually used is inside tests. Let's remove column breakpoints from the protocol for now, and reintroduce them after we've cleaned up the rest of the breakpoint code.
Assignee | ||
Comment 1•10 years ago
|
||
So as it turns out, we cannot get rid of column breakpoints, *because* they are broken at the moment.
Some of our source mapping tests use column breakpoints to set a breakpoint on a line. I wondered why that was, since there is nothing in those tests that distinguishes these breakpoints from normal line breakpoints. We should therefore be able to replace those column breakpoints with line breakpoints, I thought.
Well, turns out there are several things wrong with line breakpoints that prevent this from working. First of all, line breakpoints on source mapped sources are converted to column breakpoints. We're currently doing that wrong in that a single line breakpoint gets converted to a single column breakpoint (it could be multiple), but that wouldn't be a problem for these tests as long as we set a breakpoint on the first column on the line that has executable code.
With that in mind, I expected to be able to simply replace setBreakpoint({ line: 20, column: 7 }) with setBreakpoint({ line: 20, column: 0}), with the latter being equivalent to setBreakpoint({ line: 20 }). Turns out that that's not the case if the line is indented. If the line is indented, the source map library finds the closest mapping that is *smaller* than the one requested, so we end up on line 19.
That's obviously the wrong thing to do, so I've opened bug 1126190 to address that problem. In the meantime, we'll have to stick with column breakpoints for a bit longer.
Assignee: nobody → ejpbruel
Assignee | ||
Comment 2•10 years ago
|
||
This patch replaces the location object passed to setBreakpoint with a line and column. I eventually want to get rid of the column argument as well (see the comment above for an explanation of why this is not yet possible at the moment).
Note that this patch is based on top of the patch in bug 1123693.
Attachment #8555141 -
Flags: review?(jlong)
Assignee | ||
Updated•10 years ago
|
Attachment #8555141 -
Flags: review?(jlong) → review?(nfitzgerald)
Updated•10 years ago
|
Blocks: dbg-breakpoint
Comment 3•10 years ago
|
||
Comment on attachment 8555141 [details] [diff] [review]
patch
Review of attachment 8555141 [details] [diff] [review]:
-----------------------------------------------------------------
::: toolkit/devtools/server/actors/script.js
@@ +2726,5 @@
>
> _createBreakpoint: function(loc, originalLoc, condition) {
> + return this.setBreakpoint(originalLoc.line, originalLoc.column, condition)
> + .then(response =>
> + {
Nit: { on same line as =>
@@ +2912,4 @@
> });
> },
>
> + setBreakpointForActor: function (actor) {
Need doc comments -- what does this do?
Attachment #8555141 -
Flags: review?(nfitzgerald) → review+
Assignee | ||
Comment 4•10 years ago
|
||
Try push for this patch:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=816c4f3d0740
Assignee | ||
Comment 5•10 years ago
|
||
Several oranges on try, probably due to errors introduced during rebasing.
New try push with errors fixed:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=a09b9adf6bf1
Assignee | ||
Comment 6•10 years ago
|
||
Try looks green, landing on fx-team:
https://hg.mozilla.org/integration/fx-team/rev/88f46f6098e8
Comment 7•10 years ago
|
||
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 38
Updated•6 years ago
|
Product: Firefox → DevTools
You need to log in
before you can comment on or make changes to this bug.
Description
•