Open Bug 740548 (dbg-watchpoints) Opened 8 years ago Updated 23 days ago

[meta] Add Watchpoints in the devtools

Categories

(DevTools :: Debugger, enhancement, P3)

enhancement

Tracking

(Not tracked)

REOPENED

People

(Reporter: dangoor, Unassigned)

References

(Depends on 14 open bugs, Blocks 2 open bugs)

Details

(Keywords: meta)

Attachments

(1 file)

This was a suggestion that I received (alas, I forget where I saw it!)

It would be nice if the debugger could break when a variable's value changed. That would make it easier to spot unexpected changes. Apparently, Visual Studio supports this for unmanaged code[1]. I don't know if this is common in other environments.

1: http://stackoverflow.com/questions/160045/visual-studio-debugger-break-when-a-value-changes
This is in our plans, however the required SpiderMonkey API isn't there, yet.

In terms of user interface, what would be the best way to expose this?

a) Context menu on the variable in the property view, with the option "Break on change"?
b) In the future Watch Expression view, have an expression with a single variable name create a watchpoint?
c) A separate Watch Variables view?
d) ?
Depends on: 638053
OS: Mac OS X → All
Priority: -- → P3
Hardware: x86 → All
Version: unspecified → Trunk
(In reply to Panos Astithas [:past] from comment #1)
> In terms of user interface, what would be the best way to expose this?
> 
> a) Context menu on the variable in the property view, with the option "Break
> on change"?
> b) In the future Watch Expression view, have an expression with a single
> variable name create a watchpoint?
> c) A separate Watch Variables view?
> d) ?

Context menu in the property view makes sense.

I don't know what the Watch Expression view will look like... is it a list of conditional breakpoints where the expressions are displayed? (From looking at bug 727429, I'm not clear on whether "watch expressions" are conditional breakpoints or something different...)
(In reply to Kevin Dangoor from comment #2)
> (In reply to Panos Astithas [:past] from comment #1)
> > In terms of user interface, what would be the best way to expose this?
> > 
> > a) Context menu on the variable in the property view, with the option "Break
> > on change"?
> > b) In the future Watch Expression view, have an expression with a single
> > variable name create a watchpoint?
> > c) A separate Watch Variables view?
> > d) ?
> 
> Context menu in the property view makes sense.
> 
> I don't know what the Watch Expression view will look like... is it a list
> of conditional breakpoints where the expressions are displayed? (From
> looking at bug 727429, I'm not clear on whether "watch expressions" are
> conditional breakpoints or something different...)

Watch expressions are expressions the debugger evaluates each time it enters the paused state. I envision a list of (expression,result) tuples as the UI, same as Firebug and WebKit. But now that I think of it, it wouldn't work right with the watchpoint API, so we probably need a different UI. So, context menu to set and an additional view (group in the accordion-like UI we have) to display the list of watched objects and allow watchpoint removal? Or a decorator icon on the variable to toggle watchpoint functionality?

Honza, does Firebug expose a UI for using Object.prototype.watch to inspect changes to variables?
(In reply to Kevin Dangoor from comment #2)
> I don't know what the Watch Expression view will look like... is it a list
> of conditional breakpoints where the expressions are displayed? (From
> looking at bug 727429, I'm not clear on whether "watch expressions" are
> conditional breakpoints or something different...)

This reminded me that I hadn't filed a bug for implementing conditional breakpoints, so bug 740825 will cover that work.
This would be so awesome! I've discussed this topic with Jorendorff and Jimb (adding them in copy) back in December. They mentioned that since variables are heavily optimized in SpiderMonkey, it could require generating a different machine code.
Blocks: 738965
Duplicate of this bug: 835878
Firebug has this feature so it must be possible.
Component: Developer Tools: Debugger → Developer Tools: User Stories
Summary: Break when variable value changes → Watchpoints
Component: Developer Tools: User Stories → Developer Tools: Debugger
Product: Firefox → DevTools
We have it now:
https://developer.mozilla.org/en-US/docs/Tools/Debugger/How_to/Set_Watch_Expressions
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Summary: Watchpoints → Add Watchpoints in the devtools

(In reply to Sylvestre Ledru [:sylvestre] from comment #8)

We have it now:
https://developer.mozilla.org/en-US/docs/Tools/Debugger/How_to/Set_Watch_Expressions

Hi Sylvestre!

I just came here looking for the same thing as this bug describes.

"It would be nice if the debugger could break when a variable's value changed"

Watch-Expressions only allow the user to see the value of variables when a break naturally occurs.

Is this not different?

Hi Alec, good point. I'll re-open this bug. We have watch points on the roadmap. It would be a really nice feature.

Status: RESOLVED → REOPENED
Resolution: FIXED → ---

my bad, thanks

Severity: normal → enhancement
Keywords: feature

Here are some initial mockups design.

Miriam and I sketched out a server Object.defineProperty approach today.

Brian, what would we need to do in spider monkey to make this real?

Notes:

  1. it would be nice to auto-bind watch points to support immutable objects
  2. it would be nice to support property delete
  3. it would be nice to integrate into the console
Flags: needinfo?(bhackett1024)

Minimizing the impact on spidermonkey internals seems like a good approach. Redefining properties to have new getters and setters is nice and minimal impact, but it won't handle delete, reconfigurations (we don't want site code to be able to remove special getters/setters) or accessing the property definition (we don't want site code to be able to see the getters/setters either). These should all have pinchpoints in the VM and we could have a debugger trap there that can observe changes to properties, allowing the debugger to pause, to modify the property being defined or the property info being read back out. I think this would take care of everything except proxies, which seem best to just leave alone for now.

Flags: needinfo?(bhackett1024)
Depends on: 1565351
Attached patch WIPSplinter Review

WIP from last month, which works in simple cases but doesn't modify spidermonkey, allowing site code to tell that new setters have been installed on their properties, redefine those setters, etc. I'm not actively working on this, just attaching this for posterity.

Assignee: nobody → bhackett1024
Assignee: bhackett1024 → nobody
Depends on: 1574190
No longer depends on: 1574190
Keywords: featuremeta
Summary: Add Watchpoints in the devtools → [meta] Add Watchpoints in the devtools
Depends on: 1574190
Depends on: 1574193
Alias: dbg-watchpoints
Depends on: 1574192
Depends on: 1574200
Depends on: 1574343
No longer depends on: 1574343
Depends on: 1578969
Depends on: 1580585
Depends on: 1580586
Depends on: 1580591
Depends on: 1581562
Depends on: 1581945
Depends on: 1582182
Depends on: 1581958
Depends on: dbg-watchpoints-m1
No longer depends on: 1582084
No longer depends on: 1582093
No longer depends on: 1581958
No longer depends on: 1582182
No longer depends on: 1581562
No longer depends on: 1581945
No longer depends on: 1574190
Depends on: 1582093
Blocks: 1593100
Depends on: 1593101
Depends on: 1601311
Depends on: 1604865
Depends on: 1604866
Depends on: 1619993
Depends on: 1620650
Depends on: 1620651
Depends on: 1646489
Depends on: 1646490
Depends on: 1646492
Depends on: 1646517
You need to log in before you can comment on or make changes to this bug.