1486381 - [Object inspector] Expanded object loses its name instead of losing the `{}` summary

Status: RESOLVED DUPLICATE of bug 1608571

(DevTools :: Console, defect, P5)

Description

[Florens Verschelde :fvsch]

Filed in Console, but this might affect the Debugger too.

STR:
1. console.log(Math);
2. console.log({});
3. console.log({ a: 1, b: 2 });

Expected in collapsed mode:
▶︎ Math { … }
▶︎ Object { }
▶︎ Object { a: 1, b: 2 }

Actual results in collapsed mode:
▶︎ Math { … }
▶︎ Object {  }
▶︎ Object { a: 1, b: 2 }

(So far, so good. The two spaces in the summary for the empty object is not ideal, a single space or zero space might be better, but that’s a detail.)

Expected in expanded mode:
▼ Math
▼ Object
▼ Object

Actual results in collapsed mode:
▼ Math
▼ {}
▼ {…}

I’m not sure what is going on here. It looks like a bug, but maybe was it decided at some point to keep the object summary ({} or {…}) in the first line in expanded mode? If that is intentional:

1. I respectfully disagree. :) The {} syntax suggests that the object starts and ends on that first line, which is inconsistent with showing its content in the next lines.
2. It should probably be consistent with other objects, such as Math or the result of `window.matchMedia('screen')`.
3. It should not lose the “Object” label.

Comment 1

[Nicolas Chevobbe [:nchevobbe]]

The use of curly brackets when expanded is wanted indeed.
We switch the reps to "TINY" mode when we expand a node.
TINY mode is what is used in debugger's scope panel for example.
`{}` is used because it is short (hence save precious space) and well spread.
Non-trivial objects (Math, Map, WeakMap, …) do keep their "title" so we don't confuse people.

The part I tend to agree with is that we could "open" and close the object like : 

▶︎ Object { a: 1}

->

▼ {
|   a: 1
|   <prototype>: Object { … }
| }

Comment 2

[Florens Verschelde :fvsch]

Good to know that it’s intended behavior and not a rogue bug.

I still suspect the current behavior might be confusing for users. 
There might be four potential sources of confusion:

1. Unclear or ambiguous notations, e.g. `()` is used for functions and in the label collapsed arrays (to show the array’s length). And while both `{}` and `[]` might be familiar as “object” and “array” to users, I’m not sure `()` for function will be understood. What's more, information being reduced to punctuation symbols like `()`, `[]` and `{}`, with no text labels, might be an accessibility issue.

2. No permanence of information: when you change the collapsed state, things jump around; it can be hard to remember what line you were looking at (this one bit me a few times), and it can be hard to remember the information you just lost (was that an Object, a function, an Array?).

3. Lack of consistency: different objects being rendered differently (simple objects and native ones).

4. Giving the wrong idea: notations that look like a “closed” object or array (`{}` and `[]`), then followed by several lines of the object's content.

Comment 3

[Julian Descottes [:jdescottes]]

The "saving space" argument makes sense for nested objects when you log on a single line something like `({ a : { b : { c : 1 }}, d : new Array(10000) })`, but then I guess the question is "should we really use TINY representation when expanding"? Horizontal space is less likely to be an issue in this scenario.

Did we discuss about keep the same display when collapsed and expanded?

Comment 4

[Florens Verschelde :fvsch]

It does make sense to use the TINY representation in object summaries (or previews or however the collapsed details are named). But not particularly for the object label itself, IMO.

Another example of a very noticeable change:

▶︎ <a href="/Au-service-des-employeurs" title="Au service des employeurs - rubrique active"> [+]

Becomes:

▼  a  [+]

(Where [+] is the "Inspect element" button.)
This form would be more understandable IMO:

▼ <a> [+]

Comment 5

[Nicolas Chevobbe [:nchevobbe]]

I filed https://github.com/devtools-html/debugger.html/issues/6893 to fix this (code lives in the debugger repo)

Comment 6

[Nicolas Chevobbe [:nchevobbe]]

This was fixed in Bug 1608571