Support debugName on constructors in the webkit inspector
Reported by wyc...@gmail.com, Feb 29 2012
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 possible. 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.
Feb 29 2012,
Mar 20 2012,
Please provide the sample page to reproduce this issue.
Mar 29 2012,
Mar 7 2013,
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.
Mar 10 2013,
Apr 6 2013,
Nov 14 2013,
Nov 14 2013,
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.
Dec 2 2013,
Closing in favor of displayName
Sign in to add a comment