RESOLVED FIXED 19155
Inspector should support console.dir
https://bugs.webkit.org/show_bug.cgi?id=19155
Summary Inspector should support console.dir
Adam Roben (:aroben)
Reported 2008-05-20 16:15:04 PDT
The Inspector should support console.dir for Firebug parity.
Attachments
proposed patch (9.87 KB, patch)
2008-08-14 04:55 PDT, Keishi Hattori
timothy: review-
ObjectPropertiesSection (8.66 KB, patch)
2008-08-14 23:39 PDT, Keishi Hattori
timothy: review-
screenshot (174.43 KB, image/png)
2008-08-14 23:40 PDT, Keishi Hattori
no flags
Fixed (7.81 KB, patch)
2008-08-15 06:55 PDT, Keishi Hattori
timothy: review+
Mark Rowe (bdash)
Comment 1 2008-05-20 16:23:02 PDT
Keishi Hattori
Comment 2 2008-08-14 04:55:19 PDT
Created attachment 22788 [details] proposed patch I was going for a quick hack job, but I think it works quite well.
Timothy Hatcher
Comment 3 2008-08-14 15:30:10 PDT
Can you attach a screenshot?
Timothy Hatcher
Comment 4 2008-08-14 15:45:40 PDT
Comment on attachment 22788 [details] proposed patch This is exciting! I am r-ing this because it should reuse other code we have to show object properties. WebInspector.ObjectPropertiesSection You should give DirMessageLevel a sensible name, maybe ObjectMessageLevel. The more I think about the message levels the more we are abusing them. We almost need a type identifier for console messages. And this would use a custom type with the log level. Group should have a type too, and be log level. Make sense? ConsoleDomInspector is not a great name. And I don't think we need another object for that, we can just make console message know how to show this message type.
Timothy Hatcher
Comment 5 2008-08-14 15:55:44 PDT
(In reply to comment #4) Opps. Didn't mean to hit submit yet. I think you can remove WebInspector.ConsoleDomProperty and just append a WebInspector.ObjectPropertiesSection to the in the console message. This will give you all the behavior of the Properties sidebar pane. You can look in PropertiesSidebarPane.js and ScopeChainSidebarPane.js to see how they are used. It should be as simple as: var propertiesSection = new WebInspector.ObjectPropertiesSection(object, title, null, null, true); propertiesSection.element.section = propertiesSection; // Store a reference so the section object isn't collected. consoleMessageElement.appendChild(propertiesSection.element); The title var will be tricky. It would be nice to know the expression that was passed to console.dir. But I don't think we have that. So just pass null for the title and ObjectPropertiesSection will use the Object name for toString. Let me know if you have any issues using this in the console! We might need to add some style rules for the console use.
Timothy Hatcher
Comment 6 2008-08-14 15:57:33 PDT
(In reply to comment #5) > (In reply to comment #4) > > propertiesSection.element.section = propertiesSection; // Store a reference so > the section object isn't collected. Or better yet, the ConsoleMessage can hold a reference to the section object.
Adam Roben (:aroben)
Comment 7 2008-08-14 16:04:32 PDT
(In reply to comment #6) > (In reply to comment #5) > > (In reply to comment #4) > > > > propertiesSection.element.section = propertiesSection; // Store a reference so > > the section object isn't collected. > > Or better yet, the ConsoleMessage can hold a reference to the section object. Won't the propertiesSection be kept alive by the event handlers that reference it?
Keishi Hattori
Comment 8 2008-08-14 23:39:23 PDT
Created attachment 22811 [details] ObjectPropertiesSection ObjectPropertiesSection worked great. I modified the css to look more natural in the console. I also tweaks the "webkit-profile://" part and linkify part because it raised some errors. I totaly agree with creating a type property to the messages but I thought I could do it later(after the console.group patch lands). The value only displays one row of information so that might be a problem(it looks nice and compact though).
Keishi Hattori
Comment 9 2008-08-14 23:40:05 PDT
Created attachment 22812 [details] screenshot
Timothy Hatcher
Comment 10 2008-08-15 06:13:30 PDT
why the change to how __lookupGetter__ is tested for on the object? file a new bug about the profile linkify issue, but the change looks great!
Timothy Hatcher
Comment 11 2008-08-15 06:15:18 PDT
(In reply to comment #10) > why the change to how __lookupGetter__ is tested for on the object? You should mention it in the ChangeLog!
Keishi Hattori
Comment 12 2008-08-15 06:20:07 PDT
(In reply to comment #10) > why the change to how __lookupGetter__ is tested for on the object? > > file a new bug about the profile linkify issue, but the change looks great! > When I use it for a built-in object like a string, it said I can't use the "in" operator on it.
Timothy Hatcher
Comment 13 2008-08-15 06:21:29 PDT
Comment on attachment 22811 [details] ObjectPropertiesSection The __lookupGetter__ change is wrong. You need to quote the property name in braket notation. Otherwise you are looking for a property who's name is "[Function]" or whatever the toString result for window.__lookupGetter__ is. Also explain why you made the change in the ChangeLog.
Keishi Hattori
Comment 14 2008-08-15 06:55:56 PDT
Created attachment 22815 [details] Fixed I fixed it. I separated the linkifyStringAsFragment bug to Bug 20399: https://bugs.webkit.org/show_bug.cgi?id=20399
Timothy Hatcher
Comment 15 2008-08-15 10:35:39 PDT
Landed in r35787.
Note You need to log in before you can comment on or make changes to this bug.