Closed
Bug 901271
Opened 12 years ago
Closed 11 years ago
Disabled breakpoints are lost on page reload
Categories
(DevTools :: Debugger, defect, P2)
Tracking
(Not tracked)
RESOLVED
FIXED
Firefox 26
People
(Reporter: Optimizer, Assigned: vporof)
Details
Attachments
(6 files, 1 obsolete file)
17.95 KB,
patch
|
fitzgen
:
review+
|
Details | Diff | Splinter Review |
7.65 KB,
patch
|
fitzgen
:
review+
|
Details | Diff | Splinter Review |
5.22 KB,
patch
|
fitzgen
:
review+
|
Details | Diff | Splinter Review |
7.46 KB,
patch
|
fitzgen
:
review+
|
Details | Diff | Splinter Review |
7.59 KB,
patch
|
Details | Diff | Splinter Review | |
7.22 KB,
patch
|
Details | Diff | Splinter Review |
Using latest nightly ,
1) go to http://htmlpad.org/debugger/
2) Put breakpoints on line 23 and 33.
3) hit "Click Me" and ensure both breakpoints are hit.
4) Disable the breakpoint of line 23.
5) hit "Click me" again to see that breakpoint on line 23 is not being hit.
6) Reload the page.
7) The source list panel has only 1 breakpoint that was added on line 33.
expected : both breakpoints are preserved, lien 23 one being disabled.
Updated•11 years ago
|
Assignee: nobody → nfitzgerald
Priority: -- → P2
Assignee | ||
Comment 1•11 years ago
|
||
This is because disabled breakpoints are actually removed from the server, but preserved in the UI (in the sources list). When a page is refreshed, the sources list is emptied, and there are no breakpoints on the server, so, yeah...
Ideally, disabling breakpoints wouldn't be a synonym to removing them. It'd be nice if we had a disableBreakpoint packet that we could send to breakpoint actors.
What do you think, Nick?
Assignee | ||
Updated•11 years ago
|
Assignee: nfitzgerald → vporof
Status: NEW → ASSIGNED
Flags: needinfo?(jimb)
Assignee | ||
Comment 3•11 years ago
|
||
Assignee | ||
Comment 4•11 years ago
|
||
This does the trick. I'd implement new tests if I were able to run them :(
Assignee | ||
Comment 5•11 years ago
|
||
Attachment #804063 -
Flags: review?(nfitzgerald)
Assignee | ||
Comment 6•11 years ago
|
||
Attachment #804064 -
Flags: review?(nfitzgerald)
Assignee | ||
Updated•11 years ago
|
Attachment #803941 -
Flags: review?(nfitzgerald)
Assignee | ||
Updated•11 years ago
|
Attachment #803943 -
Flags: review?(nfitzgerald)
Assignee | ||
Comment 7•11 years ago
|
||
Wrong patch lolol.
Attachment #804064 -
Attachment is obsolete: true
Attachment #804064 -
Flags: review?(nfitzgerald)
Attachment #804068 -
Flags: review?(nfitzgerald)
Comment 8•11 years ago
|
||
Comment on attachment 803941 [details] [diff] [review]
Part 1: Remove actor id dependencies from the debugger breakpoints view
Review of attachment 803941 [details] [diff] [review]:
-----------------------------------------------------------------
Looks good to me. Please upload diffs with 8 lines of context in the future.
::: browser/devtools/debugger/debugger-panes.js
@@ +139,5 @@
> * @param object aOptions [optional]
> * @see DebuggerController.Breakpoints.addBreakpoint
> */
> addBreakpoint: function(aBreakpointData, aOptions = {}) {
> + let location = aBreakpointData.location;
let { location } = aBreakpointData;
is shorter, if you like ;)
Attachment #803941 -
Flags: review?(nfitzgerald) → review+
Comment 9•11 years ago
|
||
Comment on attachment 803943 [details] [diff] [review]
Part 2: Preserve disabled breakpoints and re-add them in the views after a target navigation
Review of attachment 803943 [details] [diff] [review]:
-----------------------------------------------------------------
::: browser/devtools/debugger/debugger-controller.js
@@ +1591,5 @@
> * @param object aBreakpointData
> * Information about the breakpoint to be shown.
> * This object must have the following properties:
> * - location: the breakpoint's source location and line number
> + * - state: the breakpoint's state, either "enabled" or "disabled"
Do we expect to eventually have more states? If not, I'd prefer having an "enabled" property that is a boolean to a "state" property that is one of two strings. When you have a string property that is supposed to be one of two strings, you open up the gates for bugs where `state !== "enabled" && state !== "disabled"`.
I'm willing to be convinced otherwise, but at this point I'd ask you to change to a boolean "enabled" property before commiting.
@@ +1642,5 @@
> + * Gets all Promises for the BreakpointActor client objects that are
> + * either enabled (added to the server) or disabled (removed from the server,
> + * but for which some details are preserved).
> + */
> + get _addedOrDisabled() {
This could be a generator, if you like.
::: browser/devtools/debugger/debugger-panes.js
@@ +134,5 @@
> * @param object aBreakpointData
> * Information about the breakpoint to be shown.
> * This object must have the following properties:
> * - location: the breakpoint's source location and line number
> + * - state: the breakpoint's state, either "enabled" or "disabled"
ditto
Attachment #803943 -
Flags: review?(nfitzgerald) → review+
Updated•11 years ago
|
Attachment #804063 -
Flags: review?(nfitzgerald) → review+
Comment 10•11 years ago
|
||
Comment on attachment 804068 [details] [diff] [review]
Actual tests for part 2
Review of attachment 804068 [details] [diff] [review]:
-----------------------------------------------------------------
::: browser/devtools/debugger/test/browser_dbg_breakpoints-disabled-reload.js
@@ +83,5 @@
> + yield ensureSourceIs(aPanel, "-02.js");
> + yield verifyView({ disabled: false, visible: false });
> +
> + // Spin the event loop before causing the debuggee to pause, to allow
> + // this function to yield first.
Redundant comment; you have a larger comment above these functions that says this.
@@ +100,5 @@
> + yield ensureSourceIs(aPanel, "-02.js");
> + yield verifyView({ disabled: true, visible: false });
> +
> + // Spin the event loop before causing the debuggee to pause, to allow
> + // this function to yield first.
Redundant comment.
Attachment #804068 -
Flags: review?(nfitzgerald) → review+
Assignee | ||
Comment 11•11 years ago
|
||
Assignee | ||
Comment 12•11 years ago
|
||
(In reply to Nick Fitzgerald [:fitzgen] from comment #10)
> Comment on attachment 804068 [details] [diff] [review]
Thanks for the reviews. Agreed with all comments.
Assignee | ||
Comment 13•11 years ago
|
||
Assignee | ||
Comment 14•11 years ago
|
||
Assignee | ||
Comment 15•11 years ago
|
||
https://hg.mozilla.org/integration/fx-team/rev/c5c140cca0cf
https://hg.mozilla.org/integration/fx-team/rev/87860bf00124
https://hg.mozilla.org/integration/fx-team/rev/851e60b68784
https://hg.mozilla.org/integration/fx-team/rev/7ec66af65872
Whiteboard: [fixed-in-fx-team]
Comment 16•11 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/c5c140cca0cf
https://hg.mozilla.org/mozilla-central/rev/87860bf00124
https://hg.mozilla.org/mozilla-central/rev/851e60b68784
https://hg.mozilla.org/mozilla-central/rev/7ec66af65872
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Whiteboard: [fixed-in-fx-team]
Target Milestone: --- → Firefox 26
Updated•7 years ago
|
Product: Firefox → DevTools
You need to log in
before you can comment on or make changes to this bug.
Description
•