143650 2015-04-12 14:23:51 -0700 Web Inspector: ObjectTree Property Path doesn't work for objects logged via console.log 2016-12-13 15:34:29 -0800 1 1 1 Unclassified WebKit Web Inspector 528+ (Nightly build) All All NEW InRadar P2 Normal --- 1 burg webkit-unassigned inspector-bugzilla-changes jonowells webkit-bug-importer oldest_to_newest 1084694 0 burg 2015-04-12 14:23:51 -0700 it returns bogus paths, using `this` as the root expression. 1084695 1 webkit-bug-importer 2015-04-12 14:24:00 -0700 <rdar://problem/20513381> 1084753 2 joepeck 2015-04-13 01:44:05 -0700 (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"? 1084782 3 burg 2015-04-13 07:00:48 -0700 (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`. 1084783 4 burg 2015-04-13 07:02:08 -0700 (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). 1084845 5 timothy 2015-04-13 09:59:59 -0700 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. 1084847 6 burg 2015-04-13 10:02:53 -0700 (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.