236 bytes, text/html
>>> 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.
Component: Developer Tools: Canvas Debugger → Developer Tools: Debugger
You need to log in before you can comment on or make changes to this bug.