Bug 143650 – Web Inspector: ObjectTree Property Path doesn't work for objects logged via console.log

• Status: NEW
• Component: Web Inspector

[Brian Burg]

it returns bogus paths, using `this` as the root expression.

[Radar WebKit Bug Importer]

<rdar://problem/20513381>

[Joseph Pecoraro]

(In reply to comment #0)
> it returns bogus paths, using `this` as the root expression.

This is currently expected behavior. "this" is the default when we don't know the value.

Unless the value is a $n value (or the special case of top level names in the Scope Chain Sidebar) we don't know how to reference the top level object.

Take this for example:

    console.log([a:1});
    console.log(functionReturningObject());

There is no reference to those objects. So we say "this".

However for:

    js> obj = {a:1}; dir(obj)
    {a: 1} = $1

In this case, we know the root level object is $1 and can use that.

If someone does:

    console.log(event);

By the time the event has passed, if we showed "event.type" as the property path that could be misleading if "event" no longer refers to the event at the time it was logged.

--

- Is there a specific case you have in mind that you think we should improve?
- Do you think there would be a better default name then "this"?

[Brian Burg]

(In reply to comment #2)
> (In reply to comment #0)
> > it returns bogus paths, using `this` as the root expression.
> 
> This is currently expected behavior. "this" is the default when we don't
> know the value.
> 
> - Is there a specific case you have in mind that you think we should improve?
> - Do you think there would be a better default name then "this"?

Well, since the logged object can be previewed, why can't we give it a $n binding? It was just confusing to me why some expandable (remote?) objects were given numbers and others aren't. If its not possible to bind, maybe call it /(value)/ instead of `this`.

[Brian Burg]

(In reply to comment #3)
> (In reply to comment #2)
> > (In reply to comment #0)
> > > it returns bogus paths, using `this` as the root expression.
> > 
> > This is currently expected behavior. "this" is the default when we don't
> > know the value.
> > 
> > - Is there a specific case you have in mind that you think we should improve?
> > - Do you think there would be a better default name then "this"?
> 
> Well, since the logged object can be previewed, why can't we give it a $n
> binding? It was just confusing to me why some expandable (remote?) objects
> were given numbers and others aren't. If its not possible to bind, maybe
> call it /(value)/ instead of `this`.

And if this would create too many $n bindings, then maybe assign a new one when the object is expanded or right-clicked (or other user interaction to hint a shortcut might be useful).

[Timothy Hatcher]

Yes, there is concern about too many objects getting $n assignments. Also, what object gets signed for console.log("message %o", foo, bar, baz), etc.

Doing it on expend is interesting, but might still be mysterious to users.

You can get a $n for a logged object by using the "Log Value" context menu item.

[Brian Burg]

(In reply to comment #5)
> You can get a $n for a logged object by using the "Log Value" context menu
> item.

OH! I had no idea. Maybe this could be exposed in the UI better:

Show ' = [eye]' as the binding (like for getters), and when the eye is clicked, turn it into an $n. I don't know that an eye is the best glyph... :) Then, logging a path can automatically click the eye.