1035545 - preview for new String should be like an object, not like a string

Status: VERIFIED FIXED

(DevTools :: Console, defect, P3)

Description

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

Attachment: console-new-string.png

Comment 1

[Kyle Simpson]

Note: seems to be true of all boxed values, not just `String`.

Comment 2

[Joe Walker [:jwalker]]

You want to know that it's not a string because typeof. But I'm not sure that chrome's representation is actually helpful is it?
Maybe the ideal representation is literally:

    new String("abc")

Comment 4

[Eddy Bruel [:ejpbruel]]

I made a rather large reply in the duplicate bug that somehow got lost :-S

The only issue I have with new String("abc") is that it may suggest that it is somehow a new instance, which isn't true. But it's clearer than all the alternatives I can come up with. To name a few: String("abc") is obviously misleading, since that's still a primitive. "abc" : String doesn't really stretch that this is a String *object* (it looks like we're redundantly stating that its a string). [[PrimitiveValue]] "abc" (in case "abc" is *not* a String object) needlessly clutters the by far more common case.

Comment 5

[Kyle Simpson]

Chrome's representation now says:

String { 0:"a", 1:"b", 2:"c", length:3, [[PrimitiveValue]]: "abc" }

That's quite verbose, and now with `[[PrimitiveValue]]` which cannot actually be accessed as a public key, it's misleading. BUT, at least it's quite clear that whatever it is, it's NOT just a primitive "abc" value.

How about this simplified representation?

String { "abc" }

...where "String" would be italicized like it is in Chrome.

Pros:

1. It's somewhat consistent with convention from Chrome, which is useful to devs to reinforce understanding rather than diverge to create confusion.

2. It's different from `String("abc")` which is obviously misleading.

3. It's much simpler than Chrome's output, but is still accurate and not misleading.

Comment 6

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

Highest priority is to not lie to developers and let them know they're dealing with an object, not a primitive.

Secondary to that is having a nice visual representation for the primitive passed into the constructor. This can even be a follow up bug.

Comment 7

[Jeff Griffiths (:canuckistani) (:⚡︎)]

(In reply to Nick Fitzgerald [:fitzgen] from comment #6)
> Highest priority is to not lie to developers and let them know they're
> dealing with an object, not a primitive.
> 
> Secondary to that is having a nice visual representation for the primitive
> passed into the constructor. This can even be a follow up bug.

+1.

Comment 8

[Kyle Simpson]

Attachment: new-boolean.png

On the twitter thread last nite, it was asked what are observable differences between primitives and their object wrappers (as if to imply that perhaps this distinction isn't important), and several examples were given.

I have one more to add to that list, the attachment shows the plain observable difference between `new Boolean(false)` and `false`, and how (other than the subtle italicism which is super easy to miss), FF's output is rather misleading.

Comment 9

[Gabriel [:gl] (ΦωΦ)]

Nick proposed 2 solutions, and we are wondering which one would be preferable. 

Proposal 1:
String ["a", "b", "c"]

Proposal 2:
String "abc" {0: "a", 1: "b", 2: "c"}

Comment 10

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

> String ["a", "b", "c"]

+1 for treating new Strings like the array like they are.

Will still need something else for bools/numbers.

Comment 11

[Kyle Simpson]

IMO, `String ["a", "b", "c"]` is misleading because it implies it's an array when it's not.

> +1 for treating new Strings like the array like they are.

Except, it's not an array. It's an array-like object. If it were an array, I'd expect to be able to do strictly-array things on it, like calling `.map(..)`, etc, which I cannot. There's lots of other non-array behaviors about them (see below), too.

----

`String "abc" {0: "a", 1: "b", 2: "c"}` is really not noticeably different or better than Chrome's version, except for the fact that it omits the part that Chrome recently added: the confusing `[[PrimitiveValue]]: "abc"`. Chrome used to just say: `String { 0: "a", 1: "b", 2: "c" }`, which I was OK with.

OTOH, the other change Chrome recently added was now they also show the `length` property, which further reinforces that it's an object with properties, so that part is nicer and less confusing.

TBH, the `0:"a", ...` part has always felt to me like a leakage of internal implementation detail. The fact that it has some (but not all) array behaviors to it is definitely not support for treating strings (or string objects) as in a common or best-practice type of thing **as arrays*. For example, IE didn't allow [0] syntax to access arrays until IE9 or IE10 (I believe?), that's why we still have that ugly `charAt(..)`. And moreover, arrays using [0] syntax are mutable, but strings and string objects are most definitely not.

All in all, I'd say strings actually have less in common with arrays (other than internal implementation) than they have in common. So trying to reinforce how they are implemented under the covers is not useful.

> Will still need something else for bools/numbers.

Yes, exactly. We should try to come up with some sort of representation that will be accurate for all of threee of the simple primitives' wrappers.

I would prefer any of:

String { "abc" }     Boolean { false }     Number { 42 }
String "abc"         Boolean false      Number 42
String { "a" "b" "c" }

Comment 12

[Joe Walker [:jwalker]]

Suppose you have

  function t(param) {
    if (typeof param == "string") {
      // do something
    }
  }

Unknown to you, param is new String("abc"). So you're confused as to why "something" isn't being done, so you've broken on the if, and you do:

>> console.log(param);

I think that this is going to tell you fastest what's going on:

    new String("abc")

Solutions like 'String "abc"' don't really help at all. "Why is it telling me that it's a string - I can see that already".

If we were super helpful we might have a link to an MDN article explaining.

Comment 13

[Kyle Simpson]

> I think that this is going to tell you fastest what's going on:
> 
>    new String("abc")

Personally, that would confuse the hell out of me.

But moreover, what if the value in question wasn't arrived at with that syntax, but was instead arrived at with `Object("abc")` or `new Object("abc")`? I don't think you could tell how it was originally constructed. If I got `new String("abc")` and I did a search for `new String(` in my code base and couldn't find it, because I should have been searching for `Object(`, then that's just as confusing/misleading as what we currently have.

But if we have to go down this route, of trying to represent the value in some way that syntactically matches how the value could have been created (I've expressed my distaste for such in other bugs), I think this would be more appropriate (avoiding the `new` and its various conotations):

Object("abc")    Object(false)     Object(42)

But then, why not just:

{ "abc" }     { false }    { 42 }

Comment 14

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

(In reply to Kyle Simpson from comment #11)
> IMO, `String ["a", "b", "c"]` is misleading because it implies it's an array
> when it's not.
> 
> > +1 for treating new Strings like the array like they are.
> 
> Except, it's not an array. It's an array-like object. If it were an array,
> I'd expect to be able to do strictly-array things on it, like calling
> `.map(..)`, etc, which I cannot. There's lots of other non-array behaviors
> about them (see below), too.

I missed the -. I meant "treating `new String`s like the array-like they are."

Comment 15

[Kyle Simpson]

> so you've broken on the if, and you do...

In all fairness, if you know about doing things like setting breakpoints to inspect values, you're probably going to be using the debugger's UI, which has the object/value inspector. So, it's an orthagonal point that THAT tool also needs to not confuse/lead astray.

Comment 16

[Gabriel [:gl] (ΦωΦ)]

Attachment: 1036001.patch

Comment 17

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

Comment on attachment 8459823 [details] [diff] [review]
1036001.patch

Review of attachment 8459823 [details] [diff] [review]:
-----------------------------------------------------------------

Make sure to add leave-open, since this doesn't fix `new Boolean` or `new Number`. Are you planning on fixing those as well?

::: toolkit/devtools/server/actors/script.js
@@ +3576,5 @@
> +    for (let i = 0; i < result.value.length; i++) {
> +      let value = threadActor.createValueGrip(result.value[i]);
> +      items.push(value);
> +
> +      if (items.length == OBJECT_PREVIEW_MAX_ITEMS) {

Nit: I think this would be nicer if you did:

const max = Math.min(result.value.length, OBJECT_PREVIEW_MAX_ITEMS);
for (let i = 0; i < max; i++) {
  ...
}

Comment 18

[Gabriel [:gl] (ΦωΦ)]

Attachment: 1035545.patch

(In reply to Nick Fitzgerald [:fitzgen] from comment #17)
> Comment on attachment 8459823 [details] [diff] [review]
> 1036001.patch
> 
> Review of attachment 8459823 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> Make sure to add leave-open, since this doesn't fix `new Boolean` or `new
> Number`. Are you planning on fixing those as well?
> 
> ::: toolkit/devtools/server/actors/script.js
> @@ +3576,5 @@
> > +    for (let i = 0; i < result.value.length; i++) {
> > +      let value = threadActor.createValueGrip(result.value[i]);
> > +      items.push(value);
> > +
> > +      if (items.length == OBJECT_PREVIEW_MAX_ITEMS) {
> 
> Nit: I think this would be nicer if you did:
> 
> const max = Math.min(result.value.length, OBJECT_PREVIEW_MAX_ITEMS);
> for (let i = 0; i < max; i++) {
>   ...
> }

Fixed nit. try: https://tbpl.mozilla.org/?tree=Try&rev=1622d1c1359e

Comment 19

[Gabriel [:gl] (ΦωΦ)]

Upon further discussion with Nick, we will be going with an object preview based on the es6 ToObject specs: https://people.mozilla.org/~jorendorff/es6-draft.html#sec-toobject

The proposed preview for String will be the following:
String { [[StringData]]: "abc", 0: "a", ... }

We will be landing the previous patch as a stop-gap until the proposal is implemented.

Comment 20

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/integration/fx-team/rev/7c3b1a192e64

Comment 21

[Joe Walker [:jwalker]]

I think there is a real danger in this fix that we're too deep in purist es6 spec land, and not in the mindset of helping someone who doesn't understand why (typeof somestring == "object").

ES6 spec writers can work this out for themselves, so we don't care about them. We should be doing something to help the people that are confused by this JS WAT moment.

Also outputting the string using 8+ chars for every char in the string seems pointless.

Comment 22

[Kyle Simpson]

+1000 Joe Walker. I do not understand why   { "abc" }   or   String { "abc" }   aren't sufficient?

Comment 23

[Mihai Sucan [:msucan]]

new String("foo") seems like it strikes the right balance for me. Not much value in having an array-like representation or es6 ToObject dump. How about just String("foo")? That would be reusable for booleans, numbers, etc.

Also, does this bug really need a stop-gap solution? Is it high priority / urgent we get a fix out for this?

Comment 24

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

The JS shell also uses (new String("abc")) FWIW. Perhaps the extra parens give a sufficient hint that their contents should not be interpreted literally.

Comment 25

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/7c3b1a192e64

Comment 26

[Kyle Simpson]

I came here hoping to make the representation LESS confusing -- that is, to make it clearer that "abc" is different from { "abc" }. As I've said a few times already in this thread, things like `String("abc")` and `new String("abc")` actually actively work **against** that goal, and make it worse in terms of confusion/conflation.

There's been several other much better ideas floated here. If none of those are acceptable (still wish someone could explain why?), just leave it alone as-is, but please don't make it more confusing.

Comment 27

[Joe Walker [:jwalker]]

(In reply to Kyle Simpson from comment #26)
> I came here hoping to make the representation LESS confusing -- ...
> things like `String("abc")` and `new String("abc")`
> actually actively work **against** that goal

We're trying to distinguish normal strings from string-like things with typeof == 'object'. Isn't using `new String` the most obvious way to do that since that's how you create them? [1]

My issue with `{ 'abc' }` as a representation is that you have to spot the `{}` AND know how to interpret them to get what it's saying. Given that this is a rare thing, I'm tempted to err on the side of verbosity over compactness in the pursuit of clarity.

[1]: Representing `new Object('abc')` by `new String('abc')` doesn't seem that bad given that `new Object('abc').constructor === new String('abc').constructor`

Comment 28

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

Rendering the object with its internal slot is the best solution IMO because it is the exact representation of these objects. It is clear that it is an object w/ properties (as opposed to a string primitive), it is clear what its [[class]] is, and it is clear what the value of its internal slot is. Being "too deep in purist es6 land" is a strawman. First, we are making debugging tools. The whole point of debugging tools is to help developers to understand **what is really happening**; eg how SpiderMonkey follows the spec. Second, this stuff is not only interesting to es6 spec writers or else we wouldn't be having this conversation and bug open in the first place.

`new String("abc")` or `(new String("abc"))` are alright /iff/ you already understand that `new String` creates something different from just a string literal. The upside is it shows how the string object was created. The downside is that you have an object, but have to do an extra click to inspect its properties.

`{ "abc" }` and `String { "abc" }` etc are not clearly objects w/ properties, nor do they make it clear how they were created like `new String` representations above. The only way they educate the user on their difference from string primitives is that they happen to be rendered different.

Comment 29

[Kyle Simpson]

(In reply to Joe Walker [:jwalker] from comment #27)

`new String("abc")` is almost universally panned as a bad-practice in normal JS development. It's very rare that there's a reason to intentionally do literally that in your programs.

As such, reinforcing that bad practice syntax by using it as the console serialization takes developers (especially those new to and learning the language) farther down paths of confusion and ill-fated development.

> Isn't using `new String` the most obvious way...

Speaking as someone who spends an awful lot of time obsessing about JS details (while writing JS books, teaching JS, etc), and in particular an awful lot of time in the developer consoles: NO.

IMO, it's the most unintuitive approach that's been suggested in this thread. It's not "inaccurate" per se (like `String("abc")` would be!), but it's the complete opposite of what I'd want my developer tools to show me.

If I'm inspecting a value, I want the developer tools to accurately and succinctly tell me WHAT the value is (no more, no less), not HOW to recreate it.

My other objection(s) to this option in comment #13 remain, so I won't repeat them.

Comment 30

[Kyle Simpson]

(In reply to Nick Fitzgerald [:fitzgen] from comment #28)
> `{ "abc" }` and `String { "abc" }` etc are not clearly objects

Almost everyone (even newbies to the language) associates a { } pair with an object. The object literal is one of the most pervasive syntactic hooks in the whole language. I cannot think of any representation that's more object-like than the { }.

> w/ properties

Why is "having properties" the important part? I think "identity as an object rather than a primitive value" is the important distinguisher.

I don't per se object to the properties being shown, except that showing properties like `[[PrimitiveValue]]` like Chrome does are confusing to developers who aren't spec wonks because they think they can do `s["[[PrimitiveValue]]"], and they cannot.

I literally had someone the other day ask me why adding `o["[[Call]]"]` to an object didn't make it return `typeof o === "function"`. That's actually a great question. I'm glad they asked it. Because it speaks exactly to this point: if we show things to people that they don't understand, THOSE THINGS WILL CONFUSE THEM.

If, OTOH, we invent a lightweight serialization format that works for all 3 primitive values equally, and it hooks into existing precedent (like understanding that { .. } are usually objects), then we've correctly identified this value as being different from the primitive, without showing them other things which are going to confuse.

Chrome now showing the `length:3` property in their serialization is a good example of something you CAN show which isn't confusing. Why? Because it's not only accurate, but it's also something the developer can directly interact with.

> nor do they make it clear how they were created like `new
> String` representations above. The only way they educate the user on their
> difference from string primitives is that they happen to be rendered
> different.

Which actually turns out to be exactly enough (again speaking as someone who teaches people JS *in* these developer consoles for a living).

Comment 31

[ljharb]

Given:
var foo = new String('foo');
foo.bar = 'baz';
console.log(foo);

Why could this not be represented as `{ "foo", bar: "baz" }` or `String { "foo", bar: "baz" }`? The same approach could work for Boolean and Number.

Since object wrappers for primitives are special cases in the language, it makes sense to me that they would be represented differently than "normal" objects.

Comment 32

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

(In reply to ljharb from comment #31)
> Since object wrappers for primitives are special cases in the language, it
> makes sense to me that they would be represented differently than "normal"
> objects.

They're not special cases "in the language". `new String("abc")` is a shortcut for creating an object that looks like this: { "0": "a", "1": "b", "2": "c", length: 3 }, with String as the prototype, which is no more special than Object.

Comment 33

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

(In reply to ljharb from comment #31)
> Given:
> var foo = new String('foo');
> foo.bar = 'baz';
> console.log(foo);
> 
> Why could this not be represented as `{ "foo", bar: "baz" }` or `String {
> "foo", bar: "baz" }`? The same approach could work for Boolean and Number.
> 
> Since object wrappers for primitives are special cases in the language, it
> makes sense to me that they would be represented differently than "normal"
> objects.

It will be represented as

  String { [[StringData]]: "foo", bar: "baz" }

under my proposal.

Comment 34

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

Seriously though, if it's an object, why not display it like any other object, namely 
> String { 0: "a", 1: "b", 2: "c", length: 3 }

After all, logging ({ 0: "a", 1: "b", 2: "c", length: 3 }) to the console would display
> Object { 0: "a", 1: "b", 2: "c", length: 3 }

I frankly don't understand why there's so much debate here :)

Comment 35

[Kyle Simpson]

(In reply to Victor Porof [:vporof][:vp] from comment #34)
> Seriously though, if it's an object, why not display it like any other
> object, namely 
> > String { 0: "a", 1: "b", 2: "c", length: 3 }
> 
> After all, logging ({ 0: "a", 1: "b", 2: "c", length: 3 }) to the console
> would display
> > Object { 0: "a", 1: "b", 2: "c", length: 3 }
> 
> I frankly don't understand why there's so much debate here :)

1. Your suggestion would be better than what it currently prints, which is just "abc" in italics with subtle clickability to accidentally discover. So on its face, it would be better, except...

2. How would you represent (as accurately) the Boolean object wrapper? What about the Number wrapper? Neither of those store their values at keyed properties that can be directly accesses, like String wrapper does. You'd be stuck inventing some other way to represent them, that's not as consistent with String. Gonna make up a property like `value` that doesn't actually exist?

Chrome has recently started showing one of the keys as [[PrimitiveValue]] (which is of course a spec-only internal slot that's inaccessible). Others here have suggested [[StringData]]. Both suffers the exact same inaccessible confusion.

So... String is just this special case, whereas we really have been trying to devise something that works nicely and consistently across all three primitive types.

Hence, my suggestion of side-stepping the properties issue entirely with    { "foo" }   { 42 }   { true }

Comment 36

[Kyle Simpson]

Attachment: obj-not-string.png

(In reply to Victor Porof [:vporof][:vp] from comment #32)
> (In reply to ljharb from comment #31)
> > Since object wrappers for primitives are special cases in the language, it
> > makes sense to me that they would be represented differently than "normal"
> > objects.
> 
> They're not special cases "in the language". `new String("abc")` is a
> shortcut for creating an object that looks like this: { "0": "a", "1": "b",
> "2": "c", length: 3 }, with String as the prototype, which is no more
> special than Object.

Actually, this is patently not true. Real String objects get internal slots (see my previous reply), which the manual object approach you suggest would not have. Moreover, see the screenshot I just attached, demonstrating clearly that the String object is more than just an object with properties and a prototype.

Comment 37

[Kyle Simpson]

(In reply to ljharb from comment #31)
> Given:
> var foo = new String('foo');
> foo.bar = 'baz';
> console.log(foo);
> 
> Why could this not be represented as `{ "foo", bar: "baz" }` 

That looks good to me. I'd also suggest explicitly (as I implied above) that it'd be perfectly sane for String objects to show their length property too:   `{ "foo", length: 3, bar: "baz" }`



> or `String { "foo", bar: "baz" }`? The same approach could work for Boolean and Number.

Also fine, same comment as above.


> Since object wrappers for primitives are special cases in the language, it
> makes sense to me that they would be represented differently than "normal"
> objects.

Yep, +1.

Comment 38

[Joe Walker [:jwalker]]

(In reply to Nick Fitzgerald [:fitzgen] from comment #28)
> ...
> Being "too deep in purist es6 land" is a strawman. First, we are making
> debugging tools. The whole point of debugging tools is to help developers to
> understand **what is really happening**; eg how SpiderMonkey follows the
> spec.

There are times when the guts of SpiderMonkey are important. But I don't think this problem is one of them.

To me, the key thing here is probably the beginner case: "Danger - you've got something that looks like a normal string, but it isn't." We need to get over that what they are doing is almost certainly already broken just because there is a string object in the system.

In this case, exposing how SpiderMonkey follows the spec is like building a tool to measure the size of the cracks in a bike helmet. There's a bigger message to get across.

Comment 39

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

(In reply to Victor Porof [:vporof][:vp] from comment #34)
> Seriously though, if it's an object, why not display it like any other
> object, namely 
> > String { 0: "a", 1: "b", 2: "c", length: 3 }

Exactly, except we should also include the internal slot so that we aren't hiding any state (which is really required for new Number/Boolean).

Comment 40

[Kyle Simpson]

(In reply to Nick Fitzgerald [:fitzgen] from comment #39)
> (In reply to Victor Porof [:vporof][:vp] from comment #34)
> > Seriously though, if it's an object, why not display it like any other
> > object, namely 
> > > String { 0: "a", 1: "b", 2: "c", length: 3 }
> 
> Exactly, except we should also include the internal slot so that we aren't
> hiding any state (which is really required for new Number/Boolean).

Because this will never, ever confuse JS developers who aren't spec wonks:

var x = new String("abc");
x; // String { 0: "a", 1: "b", 2: "c", length: 3, [[PrimitiveValue]]: "abc" }

x[0]; // "a"  --> cool
x[1]; // "b"  --> cool
x[2]; // "c"  --> cool
x.length; // 3  --> cool
x["[[PrimitiveValue]]"]; // undefined  --> WTF!?!?! I hate JavaScript, This **** is stupid.

Comment 41

[ljharb]

What about `String { 0: "a", 1: "b", 2: "c", length: 3, valueOf: function () { return "abc"; } }`? That satisfied the demonstrated desire for over-verbosity, will run in the console, and is an accurate representation of the Object-primitive.

Comment 42

[Jeff Griffiths (:canuckistani) (:⚡︎)]

Setting devedition-40 bugs to p3, filter on FB20EAC4-3FC3-48D9-B15F-0587C3987C25

Comment 43

[ljharb]

It looks like this bug keeps getting shoved farther and farther into the corner - can anyone at Mozilla respond to https://bugzilla.mozilla.org/show_bug.cgi?id=1035545#c41 as a suggestion?

Comment 44

[Tom Tromey :tromey]

A few notes on this from my perspective as a relative newbie.

The current display of new String("mumble") seems reasonable.

Here I think "reasonable" means something along the lines of "not
actively misleading" and also "clearly distinguished from possible
confounding cases".

I find many of the proposed alternatives also reasonable by this standard,
even displaying the [[internal]] notation -- this could even be an opportunity
to link to the spec to help further educate users.


The current display of new Number or new Boolean is confusing.
The italic detail is too subtle to notice (I only know about it from
reading this bug).


None of these displays do the right thing if one has attached extra
properties to an object:

x = new String("hi")
x.whatever = 23

=> String [ "h", "i" ]

Here I think it would be valuable to show these properties.

Comment 45

[Kyle Simpson]

> None of these displays do the right thing if one has attached extra properties to an object:
> => String [ "h", "i" ]

Good point. So, my proposal would/should have handled that like:

String { "hi", whatever: 23 }

Comment 46

[Kyle Simpson]

> The current display of new Number or new Boolean is confusing.

Yep, still absolutely agree. The `String [ "h", "i" ]` update made quite awhile back was a step forward, but it was only for String, and left Number and Boolean unaffected.

I still think my approach is the most flexible to handle all three cases:

String { "hi" }
Boolean { true }
Number { 42 }

Comment 47

[Tom Tromey :tromey]

Attachment: show wrapped primitives specially in console and variable view

Patch implementing new behavior.

Comment 48

[Tom Tromey :tromey]

Comment on attachment 8687347 [details] [diff] [review]
show wrapped primitives specially in console and variable view

A few notes on this patch.

First, the exact spelling of the output is a bit controversial, as can be seen
from the comments in the bug.

I chose the form suggested by Kyle because it seemed basically reasonable (according
to my criteria in comment #44), handled corner cases nicely, and was uniform across
all primitive wrappers.

However, there is one little tweak, which is that this patch suppresses some String
properties from the console output -- in particular those corresponding to the regular
string contents.

So:

new Number(23)
=> Number { 23 }

x = new Number(23); x.whatever = 7; x
=> Number { 23, whatever: 7 }

new Boolean(true)
=> Boolean { true }

new String("hi")
=> String { "hi", 3 more... }  # these are 0, 1, and length

x = new String("hi"); x[8] = "q"; x
=> String { "hi", 8: "q", 3 more... }


I also made the label in the variables view follow the new format, for Number and Boolean.

I chose not to do it for String, for two reasons.  First, the string contents are visible
by clicking the arrow to expand the properties (not true of Number or Boolean); and second,
I was worried about space.

Finally, notice in the VariablesView stringifiers, I changed the order of the byObjectClass
and byObjectKind cases.  This now uses the same order as console-output.js, which seems at
least a bit nicer; and also with the previous ordering, there was no way for, e.g., the
Number byObjectClass function to be called.

Comment 49

[Kyle Simpson]

This sounds awesome! +1

Comment 50

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

Comment on attachment 8687347 [details] [diff] [review]
show wrapped primitives specially in console and variable view

Review of attachment 8687347 [details] [diff] [review]:
-----------------------------------------------------------------

You should probably also ask gl or fitzgen to check out object.js

Comment 51

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

Comment on attachment 8687347 [details] [diff] [review]
show wrapped primitives specially in console and variable view

Review of attachment 8687347 [details] [diff] [review]:
-----------------------------------------------------------------

r=me on object.js changes

Comment 52

[Tom Tromey :tromey]

Attachment: show wrapped primitives specially in console and variable view

Rebased, added r=.

Comment 53

[Tom Tromey :tromey]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=ae6e3c194c00

Comment 54

[Tom Tromey :tromey]

Attachment: show wrapped primitives specially in console and variable view

Minor update to a couple of tests.

Comment 55

[Tom Tromey :tromey]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=04f4752e588f

Comment 56

[Pulsebot]

https://hg.mozilla.org/integration/fx-team/rev/74d91f50bad6

Comment 57

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/74d91f50bad6

Comment 58

[Md. Rahimul Islam]

I have successfully reproduce this bug on nightly 33.0a1 (2014-07-07)windows 7(32 bit)
Mozilla/5.0 (Windows NT 6.1; rv:33.0) Gecko/20100101 Firefox/33.0
Build ID:20140707030202
The bug's fix is verified latest beta 45.0b2
Mozilla/5.0 (Windows NT 6.1; rv:45.0) Gecko/20100101 Firefox/45.0
Build ID:20160201143558

Comment 59

[Vasilica Tamas, QA [:vtamas]]

Thanks Rahimul for verifying this issue!