806058 - Avoid rebuilding the entire variables tree when performing a client evaluation

Status: RESOLVED INVALID

(DevTools :: Debugger, defect, P3)

Description

[Victor Porof [:vporof][:vp]]

When doing an activeThread.eval in the frontend, framesadded is called, which has the effect of clearing the variables view and rebuilding it again. While usually not a big deal, rebuilding the view when changing a deeply nested property's value would result in lots of ulterior pauseGrip().getPrototypeAndProperties, which over wifi may cause some serious slowdowns.

Since we already have the evaluation result in the new frame's return response, we could just change the value in place in the property view, without rebuilding it entirely.

Comment 1

[Dave Camp (:dcamp)]

Do you mean this specifically for the eval used while editing properties?  Can you be confident that the eval won't have side-effects on other properties being displayed?

Comment 2

[Victor Porof [:vporof][:vp]]

(In reply to Dave Camp (:dcamp) from comment #1)
> Do you mean this specifically for the eval used while editing properties? 

Yes.

> Can you be confident that the eval won't have side-effects on other
> properties being displayed?

No.

Comment 3

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

I got a testcase: http://jsbin.com/ayimay/1
Setting a breakpoint at line 22 and changing the value of b.c to b.foo, modifies the value of b.a before the alert is shown.

Comment 4

[Victor Porof [:vporof][:vp]]

(In reply to Panos Astithas [:past] from comment #3)
> I got a testcase: http://jsbin.com/ayimay/1
> Setting a breakpoint at line 22 and changing the value of b.c to b.foo,
> modifies the value of b.a before the alert is shown.

I've got an even more trivial testcase: set a breakpoint in any function with at least one argument ('aArg'). Modify arguments[0]. Then aArg should also change.

Yeah, I didn't think this through, although I thought it may be possible to somehow infer if there will be side effects or not. It seems it's quite hard.