930685 - Inspecting a function object should show its display name.

Status: RESOLVED FIXED

(DevTools :: Debugger, defect, P3)

Description

[Jim Blandy :jimb]

Attachment: Screen shot, mouse at function whose display name should be shown

When we inspect a function object, we should show its inferred display name.

In the attached screen shot, I'm almost positive that function has a display name, and that the debug server has already told the debug client what it is; we should take the last little step and show it to the user.

We show display names in the stack already.

Comment 1

[Victor Porof [:vporof][:vp]]

(In reply to Jim Blandy :jimb from comment #0)
> 
> When we inspect a function object, we should show its inferred display name.

What would the display name be in the example above? (I'm hypothesizing a few things and I'm trying to figure out if I'm right or not).

Comment 2

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

Victor, there is Debugger.Object#displayName, which would be perfect.

benvie added a "displayString" property to object grips (or was it a new request?), which should probably just be the displayName for functions.

Or maybe displayString for function objects should be:

  "function " + fn.displayName + "(" + fn.parameterNames.join(", ") + ") { ... }"

Either way, the variables view (and therefore the debugger) should use displayString instead of object.class.

Comment 3

[Jim Blandy :jimb]

(In reply to Victor Porof [:vp] from comment #1)
> (In reply to Jim Blandy :jimb from comment #0)
> > 
> > When we inspect a function object, we should show its inferred display name.
> 
> What would the display name be in the example above? (I'm hypothesizing a
> few things and I'm trying to figure out if I'm right or not).

The "display name" is something SpiderMonkey infers for functions that don't have a name given in the code. In the SpiderMonkey shell:

js> function g() { var o = { x: function () { throw new Error("boo"); } }; return o; }
js> try { g().x() } catch (ex) { print(ex.stack); }                                    
g/o.x@typein:14
@typein:15

Error stacks use display names; here we can see that SpiderMonkey has assigned the inner anonymous function the display name "g/o.x"; display names use "/" to mean "nested inside".

Comment 4

[Victor Porof [:vporof][:vp]]

(In reply to Nick Fitzgerald [:fitzgen] from comment #2)
(In reply to Jim Blandy :jimb from comment #3)

Guys, I know what the display name *represents*.

As Nick hinted out in comment 2, the manner in which this information is displayed is a thing that can be debatable. I don't know all the rules involved for creating the inferred name string, so I'm trying to figure out if it's best to show additional information besides it, for example the actual function name (if available), the params etc.

All of the this depends on the fact that a "display name" is something that a large majority of web developers don't know about, so the syntax can be very surprising.

Comment 5

[Panos Astithas (he/him) [:past] (please ni?)]

Note that this is just one case of what bug 843004 asks for. I agree the label in comment 2 feels more rich in information for functions, compared to just the class name. The downside is that a more dense variables view becomes less easy to quickly parse, but I believe this is the right tradeoff in this case.

Comment 6

[Jim Blandy :jimb]

It seems like simply showing the name / displayName is a good compromise between "what is this???" and "oh god a pile of stuff that I probably don't care about"

Comment 7

[Victor Porof [:vporof][:vp]]

(In reply to Jim Blandy :jimb from comment #6)
> It seems like simply showing the name / displayName is a good compromise
> between "what is this???" and "oh god a pile of stuff that I probably don't
> care about"

Which do you think is more important? (this is an argument that can be used, for example, in a potential UI discussion deciding whether the display name is shown in a tooltip, or always by default, or first followed by the actual name etc.).

Comment 8

[Jim Blandy :jimb]

(In reply to Victor Porof [:vp] from comment #7)
> Which do you think is more important? (this is an argument that can be used,
> for example, in a potential UI discussion deciding whether the display name
> is shown in a tooltip, or always by default, or first followed by the actual
> name etc.).

There are three choices here:

- Display simply "Function", as we do now.

- Display "Function" and the display name.

- Display "Function", the display name, and the argument names.

The last seems like too much information to me. I filed the bug because the first is quite exasperating: the thing probably has a name, but the debugger just won't tell me what it is.

Comment 9

[Jim Blandy :jimb]

(Note that, where the function has a name given in the source code, that is always the display name. So there's never a choice between actual name and display name.)

Comment 10

[Panos Astithas (he/him) [:past] (please ni?)]

I would actually prefer what Chrome does: function foobar() {}
It displays a pseudo-toSource() label that looks intimately familiar and removes the need for the class.

Alternatively, I would pick Firebug's display: foobar()
It is less verbose, but probably familiar enough due to the parens. It would also work better for displaying arrow functions.

Comment 11

[Jim Blandy :jimb]

(In reply to Panos Astithas [:past] from comment #10)
> I would actually prefer what Chrome does: function foobar() {}
> It displays a pseudo-toSource() label that looks intimately familiar and
> removes the need for the class.
> 
> Alternatively, I would pick Firebug's display: foobar()
> It is less verbose, but probably familiar enough due to the parens. It would
> also work better for displaying arrow functions.

Either of those seems fine to me.

Comment 12

[James Long (:jlongster)]

Attachment: Screen Shot 2014-04-08 at 5.51.35 PM.png

Has this already been fixed in some other bug? I can't find a test case for this. The names of the functions seem to display well, and `displayName` is already checked for when describing a function grip.

Comment 13

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

Yeah I remember reading bugmail about when this got fixed but I can't find the bug. I guess we had two dupes. I believe Victor fixed it, so he can mark as dupe and provide the bug number :)

Comment 14

[Victor Porof [:vporof][:vp]]

(In reply to Nick Fitzgerald [:fitzgen] from comment #13)
> Yeah I remember reading bugmail about when this got fixed but I can't find
> the bug. I guess we had two dupes. I believe Victor fixed it, so he can mark
> as dupe and provide the bug number :)

I actually can't even remember if it was I who fixed it, let alone the bug number.