Open Bug 972530 Opened 7 years ago Updated 4 months ago

Object literals / JSON typed directly in web console do not output as expected

Categories

(DevTools :: Console, enhancement, P3)

enhancement

Tracking

(Not tracked)

REOPENED

People

(Reporter: bgrins, Unassigned)

References

()

Details

From a comment on our hacks post (see URL):

> Object literals don’t work in the console for some reason. e.g. “{}” returns “undefined”, “{ foo: ‘bar’ }” returns “bar”, and “{ foo: ‘foo’, bar: ‘bar’ }” raises a SyntaxError

So, typing the following input into the console leads to the following output:

{} -> undefined
{ foo: "bar" } -> "bar"
{ foo: "foo", bar: "bar" } ->  SyntaxError: missing ; before statement


Note that assigning it to a temporary variable and then logging the variable gives the expected output:

var a = {foo:"bar"}; a; -> { foo: "bar" }
var a = { foo: "foo", bar: "bar" }; a; -> { foo: "foo", bar: "bar" }
The web console expects JavaScript code and all those cases are evaluated as blocks. I don't see how it could work any other way. Chrome does the same thing FWIW.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → INVALID
We could cheat and add parens around the evaluated string, to avoid breaking *some* of our user's expectations. Not sure if that will do more harm than good though.
(In reply to Victor Porof [:vporof][:vp] from comment #2)
> We could cheat and add parens around the evaluated string, to avoid breaking
> *some* of our user's expectations. Not sure if that will do more harm than
> good though.

It would break perfectly valid code, though.
FWIW Chrome has landed support for this https://twitter.com/ChromeDevTools/status/676531222609182720.

James pasted this code into #devtools, as I understand it this is how they are detecting / fixing the input:

if (/^\s*\{/.test(text) && /\}\s*$/.test(text))
  text = '(' + text + ')';
See Also: → 1264308
Summary: Object literals typed directly in web console do not output as expected → Object literals / JSON typed directly in web console do not output as expected
I was gonna file the same bug. I agree the fix is kindof hacky. I must say I was expecting the console to behave the same as a Node prompt. Don't know how they do it, but it might be worth looking into?

Typing an object literal is most useful when debugging/'trying stuff', eg. I have a function that works as an enumerator and I want to try it on a known dummy object to see if it works. At least I'm glad to know there's a workaround to put parens around the object literal.
And indeed, it looks like that's how they do it in the Node repl too (see this helpfully verbose commit):
https://github.com/nodejs/node-v0.x-archive/commit/9ef9a9dee54a464a46739b14e8a348bec673c5a5
Reopening - I think it's worth following suit to match expectations
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Possible gotcha if the hack of Comment 4 is implemented. Someone tries:

> {foo, bar} = {foo: 2, bar: 3}

it works in the console, but not in a JS file.

Such a feature may bring convenience but also confusion.
Duplicate of this bug: 1399782
We have a couple of people asking about that from time to time. Most of them don't know that {} can be used as a block. Hiding this behind a special case would not help them understand that either. Maybe we could have a mix of 1. showing a learn more link to mdn when said error is shown, highlighting the case of console input evaluation, 2. ask if they want to wrap the input into parens in some way.

This would provide ease of use to users as well as educational material. I for one, was glad to stumble upon that bug so i was able to learn more about the language in the end.
Priority: -- → P3
Product: Firefox → DevTools
What could happen is that we accept the expression (e.g. `{keys: 10}`, but when we show the "command" in the output, it appears like that: `({keys: 10}) — input was modified [Learn more]`, where the [Learn more] part is a link taking you to an MDN page explaining what happened and why.

If this is done, make sure to do it properly. Initially, Chrome returned an object for {a:1}),({b:2} instead of a SyntaxError.

However, I agree with Jason Orendorff in bug 1264308 comment #6:

This is a longstanding JS wart and I think it's a mistake to try to paper over it. Making a clean spot in one place just makes the rest of the language look shoddy and inconsistent:

$ node
> {}+{}
'[object Object][object Object]'
> eval("{}+{}")
NaN

The main use case this would support is that users can just post JSON and have it properly expanded. Both Chrome DevTools and Node's REPL allow executing {} and pretty prints the result. As second mover, we can avoid prior mistakes and get this right the first time with much smaller investment.

where the [Learn more] part is a link taking you to an MDN page explaining what happened and why.

This makes some sense, but maybe we can identify the problem this solves. Users expect the execution to just work, are we trying to teach them to wrap objects with ()? This would inform what kind of material we need to create.

(In reply to :Harald Kirschner :digitarald from comment #13)

This makes some sense, but maybe we can identify the problem this solves. Users expect the execution to just work, are we trying to teach them to wrap objects with ()? This would inform what kind of material we need to create.

Not to wrap object in parens, since we would support it from the console, but tell them what are code blocks?

Type: defect → enhancement
Duplicate of this bug: 1578818
Duplicate of this bug: 1587026
Duplicate of this bug: 1620192
Duplicate of this bug: 1626423
Duplicate of this bug: 1644987
You need to log in before you can comment on or make changes to this bug.