Bug 30913 – Web Inspector: hover over JS "things" in source and see their values

• Component: Web Inspector (Deprecated)
• Status: RESOLVED FIXED

[Patrick Mueller]

Spawned from: https://twitter.com/siracusa/status/5259300238

   The WebKit Inspector is getting a lot better, 
   but I still really miss the ability to mouse-over 
   JavaScript variables and see their values.

Some discussion on IRC re: what the "things" are.  Expressions?  Or just variables?  Expressions which are property accesses of the form "x.y.z"?  Do we need to worry about getters?

From IRC, xenon says: "we woud likely need to limit it to properties, no functions and not getters", which I think means things that match "x.y.z", but am unsure how we detect getters.  Am thinking supporting getters, by not doing anything special with them, is probably ok - most getters are likely side-effect free, or relatively so.

Also mentioned on IRC was that the new API caretRangeFromPoint() will make this easier to implement.

[John Siracusa]

I'd start with "do what FireBug does," which seems to be variables and simple properties (e.g., x and x.y.z, where you can mouse-over x, y, or z).

The main reason I want this feature is that I find it difficult to see the values of variables when they don't fit within the "Scope Variables" sidebar area.  The FireBug-style mouse-over tooltips have plenty of room to show even very long values.  Also, even for short values, mousing over a variable is direct and doesn't require scanning a list of variables in the sidebar.

[Mark Rowe (bdash)]

Xcode has a quite reasonable UI for doing this, including an affordance for evaluating expressions that can potentially run application code.

[Keishi Hattori]

*** Bug 17239 has been marked as a duplicate of this bug. ***

[Keishi Hattori]

Created attachment 42377 [details]
demo

I don't think we need to use caretRangeFromPoint.

[Timothy Hatcher]

(In reply to comment #4)
> Created an attachment (id=42377) [details]
> demo
> 
> I don't think we need to use caretRangeFromPoint.

Awesome! You are right. Now that our syntax highlighter is better, this is good!

We should figure out when to clear the title attribute. Maybe right in mouseover, so you don't see stale data?

Also this should be while paused only i think.

Later we might want to add UI like Xcode to let you dig in and expand objects, etc.

[Keishi Hattori]

Created attachment 42390 [details]
Initial implementation

> We should figure out when to clear the title attribute. Maybe right in
> mouseover, so you don't see stale data?
> 
> Also this should be while paused only i think.
Fixed.

> Later we might want to add UI like Xcode to let you dig in and expand objects,
> etc.
I think the red dotted line around the evaluated expression in Xcode is also a nice touch.

[Timothy Hatcher]

Comment on attachment 42390 [details]
Initial implementation

> +            identElement.addEventListener("mouseover", function(event) {

Can you split out the inline functions and give them named and put them somewhere and reference them by name? They are too long to be good inline.


> +                }
> +                var expression = parts.join(".");

Put a new line between these lines.


> +                WebInspector.panels.scripts.evaluateInSelectedCallFrame(expression, false, "console", function(result, exception) {

Again break out the inline function.


> +                    function onmouseout(event) {

Brace on the next line.

[Keishi Hattori]

Created attachment 42393 [details]
Initial implementation 2

[Adam Roben (:aroben)]

Comment on attachment 42393 [details]
Initial implementation 2

It seems a little unfortunate to reevaluate the expression each time the mouse moves over it if no code has executed since last time. We could cache the result of the evaluation somewhere and then invalidate the cache the next time JS is allowed to execute.

[Timothy Hatcher]

(In reply to comment #9)
> (From update of attachment 42393 [details])
> It seems a little unfortunate to reevaluate the expression each time the mouse
> moves over it if no code has executed since last time. We could cache the
> result of the evaluation somewhere and then invalidate the cache the next time
> JS is allowed to execute.

Good point. We should do this.

[WebKit Commit Bot]

Comment on attachment 42393 [details]
Initial implementation 2

Clearing flags on attachment: 42393

Committed r50472: <http://trac.webkit.org/changeset/50472>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.