Bug 61427 – Web Inspector: improve output of console.log(object)

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

[Nikita Vasilyev]

Created attachment 94751 [details]
console.log(obj) output

Take a look at attached mockup.

The problem is console.log and console.dir don't show keys and values of an object until I click on ▶.

If you like the idea then could you give me some pointers to getting started. Which files should I edit?

[Pavel Feldman]

(In reply to comment #0)
> Created an attachment (id=94751) [details]
> console.log(obj) output
> 
> Take a look at attached mockup.
> 
> The problem is console.log and console.dir don't show keys and values of an object until I click on ▶.
> 
> If you like the idea then could you give me some pointers to getting started. Which files should I edit?

The screenshot looks nice, but we need to figure out the way that does not regress performance.

- As if today, we issue single "Runtime.evaluate" request to the backend to get a resulting object handle. We render it as "> Classname" ("> Object" in your case).
- Upon expansion, we send additional request "Runtime.getProperties" that returns properties of the object.

In your case, we would need to send evaluate, and, in case of "object" type result, we should query for its properties immediately. However, this will be slow for "window" object due to large amount of properties.

Object handle that is returned from "Runtime.evaluate" has "description" property among others. This description property is computed in InjectedScriptSource.js (you will also find source code for evalute and getProperties there). One of the solutions would be to pass optional "formatter" script snippet to the "evaluate" and other methods that would calculate object's description. You will then be able to inject a little snippet that traverses 10 first object properties (or similar), formats them as JSON and sends them back. Or we could make this formatter static so that you could assign it once (probably a better solution).

Files you will need to touch are:
- Inspector.json to declare new setFormatterScript message in Runtime domain
- InjectedScriptSource.js - add setFormatter, modify evaluate, getProperties logic to use new formatter
- InjectedScript.h/cpp - API to InjectedScriptSource.js
- Formatter code in ConsoleView.js and ObjectPropertiesSection.js so that they were using "description" as they should.

I am probably forgetting something, but it should give you a clue on the scope.

[Nikita Vasilyev]

I didn't realize that evaluation happens on the back-end. I don't think I'm able to do C++ part.

[Nikita Vasilyev]

I wonder why do we need a backend written in C++ to get all keys of an object? It seems feasible to do in pure JS https://gist.github.com/367080/#L93. Is it all about performance?

[Nikita Vasilyev]

http://elv1s.ru/files/js/getOwnPropertyNames_performance.html
Object.getOwnPropertyNames(window) took on average between 0–1ms. Looks very fast to me.

[Pavel Feldman]

(In reply to comment #4)
> http://elv1s.ru/files/js/getOwnPropertyNames_performance.html
> Object.getOwnPropertyNames(window) took on average between 0–1ms. Looks very fast to me.

Actual backend implementation of this method is JavaScript-based: http://codesearch.google.com/codesearch/p?hl=en#OAMlx_jo-ck/src/third_party/WebKit/Source/WebCore/inspector/InjectedScriptSource.js&q=InjectedScriptSource.js&exact_package=chromium&l=152

You still need to add native accessors in InjectedScript.h/cpp for the methods you add into it though.

[Yury Semikhatsky]

(In reply to comment #3)
> I wonder why do we need a backend written in C++ to get all keys of an object? It seems feasible to do in pure JS https://gist.github.com/367080/#L93. Is it all about performance?

The keys are collected in JavaScript (see Source/WebCore/inspector/InjectedScriptSource.js) while C++ bindigs are used to get access from the injected script to some parts of WebCore. Also transport for serialized JSON messages between backend and frontend is implemented in C++.

As Pavel said, in this particular case you should be able to achieve the goal using only JavaScript part. The protocole already supports evaluation in the context of inspected page and evaluation on an object. This should be enough for collecting keys.

[Patrick Mueller]

I wonder if this would be a good candidate for a "plugin"?

I actually prefer the existing output rendering, but can see how people might want the proposed one also.

[Pavel Feldman]

(In reply to comment #7)
> I wonder if this would be a good candidate for a "plugin"?
> 
> I actually prefer the existing output rendering, but can see how people might want the proposed one also.

We don't expose API to the console object formatting today. It sounds like it would increase the API surface significantly.

I think that in this case, Nikita's proposal is generic enough to incorporate it into the inspector core. It does not seem to regress anything provided that we do it in a bit more Firebug-ish manner. I.e. keep expand arrow and current behavior + render several properties inline as a part of object description.

[Nikita Vasilyev]

Should I build WebKit every time I edit back-end js files? Tools/Scripts/build-webkit takes 1h 45min for me.

[Yury Semikhatsky]

(In reply to comment #9)
> Should I build WebKit every time I edit back-end js files? Tools/Scripts/build-webkit takes 1h 45min for me.
If you're talking about InjectedScriptSource.js and DebuggerScript.js then the answer is yes since those files are first translated into C++ constants which are compiled along with the rest of inspector native code. Incremental build should be much faster than 1h45min.

[Nikita Vasilyev]

How can I do an incremental build? "build-webkit --debug", that mentioned here http://www.webkit.org/building/build.html, seems to do a full build.

[Yury Semikhatsky]

(In reply to comment #11)
> How can I do an incremental build? "build-webkit --debug", that mentioned here http://www.webkit.org/building/build.html, seems to do a full build.

Well, it should do the full build only on the first run, after that it should compile only changed files and their dependencies. There are no special flags for that. Also if you are building on Linux, I'd recommend you use gold as a linker.

What about as an alternative implementation just adding a shortcut that will expand the first expandable arrow in the current object?  The shortcut could simply be a trigger caused by the left arrow being pressed while focus is in the console and the console input is currently empt".

And if you wanted to be complete about it, the logical extension of this solution could be to keep expanding the first arrow with each left arrow keypress until you reach the end of the "tree", then go back up and start expanding at the next arrow that hasn't been expanded on any of the objects.  This way you could eventually reach an entirely expanded object at all nodes.

But just having the ability to expand the initial object when typed into the console would be huge.  A large portion of the time that something is typed into console an object is returned, and when that happens it is necessary to click on the object about 99% of the time (in my experience).

[Paul Irish]

Looks like a first pass at this was done by Pavel over in bug 66023.

Screenshot: https://bug-66023-attachments.webkit.org/attachment.cgi?id=104192

[Paul Irish]

*** This bug has been marked as a duplicate of bug 66023 ***