830822 - Implement backend support for forcing evaluation on untrusted getter properties

Status: RESOLVED FIXED

(DevTools :: Debugger, defect, P2)

Comment 1

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

See bug 820878.

Comment 2

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

We should also make sure that setting a new value for the getter, and also for the value itself (after forcing evaluation) works property when clientEvaluating.

Comment 3

[Rob Campbell [:rc] (:robcee)]

bumping this to P1. Blocking Mihai's work on integrating the VariablesView in the WebConsole.
bug 808370.

Comment 4

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

(In reply to Victor Porof [:vp] from comment #2)
> We should also make sure that setting a new value for the getter, and also
> for the value itself (after forcing evaluation) works property when
> clientEvaluating.

Setting a new getter value (as in: function) works properly since bug 831794.

Changing the value force-returned by the getter (essentially turning the whole property itself into a plain value property) needs a bit of special-casing (since the "value" node is not a real property itself, just like "get" and "set"), but the heavy lifting was also done in bug 831794. Bug 820878 will take care of the UI.

Comment 5

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

(In reply to Victor Porof [:vp] from comment #4)
> Changing the value force-returned by the getter (essentially turning the
> whole property itself into a plain value property)

Or not. That's probably not the behavior one would look for. See https://bugzilla.mozilla.org/show_bug.cgi?id=820878#c7.

Anyway, special casing the "value" node is still required, because we wouldn't want to eval("myVal.getterSetterProperty.value = 42"). Other than that, I'm pretty optimistic that there won't be any complications with setters.

Comment 6

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

Lowering priority to reflect reality, as this didn't actually block the integration of the VariablesView to the web console.

Comment 7

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

Not going to work on this soon.

Comment 8

[Eddy Bruel [:ejpbruel]]

I don't understand the purpose of this bug. Could you clarify a bit Victor?

Comment 9

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

Untrusted (non-system) getters appear as functions. Sometimes in our debugging endeavors we're interested in the value returned by said getter, not the getter function. Providing a mechanism to evaluate those getters on demand is necessary.

Comment 10

[Hallvord R. M. Steen [:hallvors]]

I don't understand this bug either. I've just tried to write a demo to explore what the current implementation does in the context of bug 967853, and it seems to me the problem is the opposite: the debugger evaluates getters all the time, and it would probably be a good idea to give the developer using the debugger more control. See http://hallvord.com/temp/moz/dbg-getter.htm for a demo.

(It's a hard problem - Chrome devtools and Opera Dragonfly fail that test too.)

Comment 11

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

Getters are evaluated for tooltips when hovering. They're not evaluated in the sidebar variable view when inspecting scopes.

Comment 12

[Hallvord R. M. Steen [:hallvors]]

Ah - thanks. I see. IMO this should be unified so page-defined getter properties appear the same way in all contexts. Preferably in a way you can both inspect the code of the getter and choose to run it and see the result. I think Chrome devtools was experimenting with something like [...] in the UI.

Comment 13

[Tim Nguyen :ntim]

The code is here: https://dxr.mozilla.org/mozilla-central/source/devtools/server/actors/object.js#457

I think it would be safe to return a value field in that function that evaluates the getter.

Comment 14

[Jason Laster [:jlast]]

I believe this is done.