Closed
Bug 1327678
Opened 7 years ago
Closed 5 years ago
After I (un)prettify script, debugger shows breakpoints at old lines, but they break in unexpected lines (lies about breakpoints)
Categories
(DevTools :: Debugger, defect)
DevTools
Debugger
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: arni2033, Unassigned)
Details
(Whiteboard: enhancement?)
Attachments
(1 file)
236 bytes,
text/html
|
Details |
>>> My Info: Win7_64, Nightly 49, 32bit, ID 20160526082509
STR_1:
1. Open attached "testcase 1"
2. Set breakpoint at line 3
3. Click button to prettify script
4. "Go drink some coffee and forget everything"
5. Click on the page
AR: Step 4 - debugger displays breakpoint at line 3, all right, it seems. Step 5 - no visible action
ER: Step 5 - debugger should break at line 3 (shouldn't lie about breakpoints).
See "Expectations" below
STR_2:
1. Open attached "testcase 1"
2. Click button to prettify script
3. Set breakpoint at line 3
4. Click button to un-prettify script
5. "Go drink some coffee and forget everything"
6. Click on the page
AR: Step 5 - debugger displays breakpoint at line 3. Step 6 - debugger breaks at line 1
ER: Step 6 - debugger shouldn't break at irrelevant lines (shouldn't lie about breakpoints).
See "Expectations" below
Expectations: No bug. Therefore, either X or Y
X) After changing script, debugger should respect breakpoint set at line 3, break at line 3,
and don't break at other lines, because it doesn't show that breakpoint refers to other line.
Y) Step 4 - debugger should distinguish breakpoints in original and prettified scripts. For example:
1) In Step 3 it could show a prompt (coming from pretty-print button) saying something like
"Currently there's no way to distinguish breakpoints set in original and prettified, so your
breakpoints will still refer to old lines, each of them can now become several lines.
In case you don't want that, SIMPLY remove all breakpoints and set them again."
2) Alternatively, it could store breakpoints separately for each "mode" (original/prettified).
Breakpoints in sidebar:
When user switches from one mode to another, breakpoints in sidebar set in previous mode
should become unchecked and display something like * to show that those breakpoints are
somehow "special". They can also become disabled (i.e. when clicking on checkbox does nothing)
with explanation shown in tooltip, when user hovers mouse over such breakpoint.
Breakpoints in codemirror instances:
Breakpoints set in previous mode should only have solid blue border, and be "transparent"
inside that border. Breakpoints set in both modes at the same line, should have
solid blue border; one half of breakpoint inside border should be "transparent",
another half of breakpoint should be solid blue. Or smth similar.
Clicking on line numbers in codemirror should only refer to breakpoints in current mode.
3) The same as (2), except breakpoints from other mode shouldn't be shown to user AT ALL.
4) Breakpoints should be "converted" from one mode to another, i.e. after changing from prettified
to original source, debugger should create new set of working breakpoints, which definitely
cover the old piece of code my breakpoint referred to before switching mode
5) Breakpoints should be "converted" from one mode to another really smart.
Which means that even if I switch from prettified to minified mode, my breakpoint still
refers to that small piece of code where I set it. If after that I switch back to prettified
mode, my original breakpoint should be restored at its old position.
If I switch from minified to prettified mode, breakpoint should be set to the very 1st
executable piece of code and refer to it while in prettified mode. If I switch back to minified
mode, my original breakpoint should be restored at its old position and refer to all line
6) The same as (4) or (5), but with some ideas from (2): debugger should
visually show that breakpoint was "converted" and originally belongs to another mode.
Comment hidden (spam) |
Component: Developer Tools: Canvas Debugger → Developer Tools: Debugger
Updated•6 years ago
|
Product: Firefox → DevTools
Comment 2•5 years ago
|
||
this relates to the old debugger
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•