New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 116220 link

Starred by 15 users

Issue metadata

Status: WontFix
Closed: Dec 2013
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug

Sign in to add a comment

Support debugName on constructors in the webkit inspector

Reported by, Feb 29 2012

Issue description

Chrome Version       : 18.0.1025.39 (Official Build 122785) beta
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
Safari 5:
Firefox 4.x:
IE 7/8/9:

What steps will reproduce the problem?
1. Create a new constructor function
2. Assign it a debugName
3. console.log(new Constructor)

What is the expected result?

The inspector should use the `debugName` as its description.

What happens instead?

The inspector uses the inferred name.

Please provide any additional information below. Attach a screenshot if

It is common for frameworks to use a shared constructor function for many different userland "classes". It would be useful for frameworks to be able to specify an alternative to the inferred name to be shown when inspecting objects derived from these classes.
Labels: -Area-Undefined Area-WebKit Feature-DevTools
Please provide the sample page to reproduce this issue.

Comment 3 by, Mar 29 2012

Status: Assigned

Comment 4 Deleted

Anything to help create stack traces would be very helpful. I'm re-writing tracekit.js with a few others and the point of the library is to normalize stack traces - with coffeescript and minifiers, most stack traces will end up being a meaningless stack of (anonymous functions)

Coffeescript could implement adding a .debugName to all functions easily, and our new library, Shield.js, could also add .debugName to many many functions it processes.
Project Member

Comment 6 by, Mar 10 2013

Labels: -Area-WebKit -Feature-DevTools Cr-Platform-DevTools Cr-Content
Project Member

Comment 7 by, Apr 6 2013

Labels: -Cr-Content Cr-Blink
Could you clarify on why "displayName" is not enough? Giving single function a name, displayName and debugName sounds like an overkill. For example, profiler will show a displayName of the constructor, while the objects created will show up with the (different) debugName?

If the only purpose of this is to decorate console.log entries, we should instead come up with extensible way of rendering objects in console. A kind of a toDebugString function that is injected by the extension and that handles rendering properly. I think srousseyā€ˇ wanted it at some point as well.
Status: WontFix
Closing in favor of displayName

Sign in to add a comment