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

Status: REOPENED

(DevTools :: Console, enhancement, P3)

Description

[Brian Grinstead [:bgrins]]

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" }

Comment 1

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

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.

Comment 2

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

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.

Comment 3

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

(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.

Comment 4

[Brian Grinstead [:bgrins]]

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 + ')';

Comment 5

[Jonathan Allard]

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.

Comment 6

[Jonathan Allard]

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

Comment 7

[Brian Grinstead [:bgrins]]

Reopening - I think it's worth following suit to match expectations

Comment 8

[Claude Pache]

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.

Comment 10

[Nicolas Chevobbe [:nchevobbe]]

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.

Comment 11

[Nicolas Chevobbe [:nchevobbe]]

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.

Comment 12

[Oriol Brufau [:Oriol]]

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

Comment 13

[:Harald Kirschner :digitarald]

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.

Comment 14

[Nicolas Chevobbe [:nchevobbe]]

(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?

Comment 22

[Artem Manushenkov]

I like the minimalistic way chrome does it

if we modify the input post factum it can make it uncomfortable to copy the input with a triple click -> command+C since it would also highlight the (). I like to do it instead of the context menu's "Copy object". there might be a way to keep the copying easy and still display the braces around. and if there isn't one we could create it

Another way to be informative could be adding an info message in between the input and the result, but it'll feel less smooth perhaps and verbose. maybe just do it once? Like a feature onboarding

i'd like to implement the feature, i'll borrow the checks the chrome console does

Comment 23

[Oriol Brufau [:Oriol]]

I wouldn't call Chrome minimalistic. The minimalistic way is following the language and treat the curly brackets as a block, instead of automagically adding parenthesis to produce an object initializer.

Comment 24

[Artem Manushenkov]

(In reply to Oriol Brufau [:Oriol] from comment #23)

I wouldn't call Chrome minimalistic.

Hi, i meant minimalistic as opposed to explaining the user the whys and the hows, as Nicolas suggested :)

Just leaving the behaviour as is would be indeed the most minimalistic option, but I really like the feature as it would make using the console more comfortable for many people. In a sense, it's like the top-level await feature, which also automagically wraps the expressions that have await in an an async IIFE

Comment 25

[Artem Manushenkov]

Attachment: Bug 972530 - [webconsole] Wrap standalone object literals in curly braces. r=nchevobbe

Comment 27

[silverwind]

Another variant of this is the expression {...1}. In Chrome,Safari and Node it logs {}, in Firefox, it logs a SyntaxError.

It seems the console is not a properly implemented JavaScript REPL, at least when it comes to object literals.

Comment 28

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The bug assignee is inactive on Bugzilla, so the assignee is being reset.