WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
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-
Details
Formatted Diff
Diff
ObjectPropertiesSection
(8.66 KB, patch)
2008-08-14 23:39 PDT
,
Keishi Hattori
timothy
: review-
Details
Formatted Diff
Diff
screenshot
(174.43 KB, image/png)
2008-08-14 23:40 PDT
,
Keishi Hattori
no flags
Details
Fixed
(7.81 KB, patch)
2008-08-15 06:55 PDT
,
Keishi Hattori
timothy
: review+
Details
Formatted Diff
Diff
Show Obsolete
(2)
View All
Add attachment
proposed patch, testcase, etc.
Mark Rowe (bdash)
Comment 1
2008-05-20 16:23:02 PDT
<
rdar://problem/5950859
>
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.
Top of Page
Format For Printing
XML
Clone This Bug