740548 - (dbg-watchpoints) [meta] Add Watchpoints in the devtools

Status: REOPENED

(DevTools :: Debugger, enhancement, P3)

Description

[Kevin Dangoor]

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

Comment 1

[Panos Astithas (he/him) [:past] (please ni?)]

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) ?

Comment 2

[Kevin Dangoor]

(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...)

Comment 3

[Panos Astithas (he/him) [:past] (please ni?)]

(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?

Comment 4

[Panos Astithas (he/him) [:past] (please ni?)]

(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.

Comment 5

[David Bruant]

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.

Comment 7

[Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe]]

Firebug has this feature so it must be possible.

Comment 8

[Sylvestre Ledru [:Sylvestre]]

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

Comment 9

[alec.muffett]

(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?

Comment 10

[Jason Laster [:jlast]]

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

Comment 11

[Sylvestre Ledru [:Sylvestre]]

my bad, thanks

Comment 12

[Jason Laster [:jlast]]

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

Comment 13

[Brian Hackett [Laid off!]]

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.

Comment 14

[Brian Hackett [Laid off!]]

Attachment: WIP

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.