[Webkit-unassigned] [Bug 27514] add support for watched expressions

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=27514





--- Comment #10 from Patrick Mueller <pmuellr at yahoo.com>  2009-09-04 15:18:26 PDT ---
(In reply to comment #9)

> _evalInInspectedWindow is used in console where we don't know whether we are on
> breakpoint or not. If watch expressions are only applicable to the paused
> state, you should use ScriptsPanel.prototype.evaluateInSelectedCallFrame or
> doEvalInCallFrame (your watch expressions are not supposed to mutate the app
> state).

As currently implemented, watch expressions are applicable outside of paused
states.  For instance, you can bring up the Web Inspector, go to the Scripts
panel, add watch expressions, and use the Refresh key to update without having
to set a break point.  Whether or not this is useful, don't know.  I can
imagine it could be.  I'm not sure if FB does this or not.

I understand the thought that watches shouldn't mutate app state, but of course
it's impossible to prevent that.  I'm not sure it's such a bad thing.  Some
power user might be able to do something useful with it.

So, for the time being, I do still need something like _evalInInspectedWindow()

> Object.describe is not available (will soon be not available) in the frontend.
> It is declared in the InjectedScript and should only be applied to the real
> objects (not proxies) in the InjectedScript.js. Look at how values
> are formatted in ConsoleView's _format method for reverence on how to render
> evaluation results instead.

I haven't looked at those, but I will.  It would be nice to be consistent in
terms of what we're displaying for a particular object, in the various places
it can be displayed.

> This snippet as well as the InspectorController.getProperties(value, true,
> callback) above seems to be a large functionality dupe of what happens in
> ObjectPropertiesSection. Why not to use ObjectPropertiesSection explicitly?
> It would handle all the bits of rendering and expansion. Doesn't it work for
> you?

I needed more behaviour than the plain old ObjectPropertiesSection had.  I did
try that first though; the watch expressions were keys in an object whose
values were the eval()'d version of the keys.  For various reasons it turned
out to be too much work to make it all work in the existing framework instead
of writing the relatively small amount of code that I did.

I do reuse a lot of the behaviour out of the ObjectProperties code; and
especially all the stuff underneath the roots of the trees - the children of
the expressions themselves are ObjectPropertiesElements (or whatever).

> I now recall that ObjectPropertiesSection can have problems rendering primitive
> values that are being returned from the evaluate without being wrapped with
> ObjectProxies. But that should be fairly easy to fix in the
> InjectedScript.evaluateOn body. It would actually simplify ConsoleView's
> formatting as well.
> If that is the case, I can fix that in the evaluate code and you would be able
> to nuke most of the duplicated code.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.