952708 - console.log escapes special characters

Status: RESOLVED FIXED

(DevTools :: Console, defect)

Description

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

console.log() now appears to escape characters like \n, so it now prints "\n" instead of a line break.  This seems to have changed when parts 2 - 4 of bug 843004 landed.

STR:

console.log("a\nb")

ER:

"a
b"

AR:

"a\nb"

Comment 1

[Mihai Sucan [:msucan]]

This is the expected behavior. We use uneval() to display strings, to ensure correct escaping. Should we change how we escape strings in quotes?

Comment 2

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

But why did it change?  We've changed our expectations in the last day?

It seems unintuitive to force the user to "imagine" the line breaks when displaying a string to the console, which has room for multi-line output.  In the object inspector, it makes more sense to show "\n" instead, since you have just one line for each value you're showing.

For a more dramatic example than the one I cited above, go to mozilla.org and open the console.  The ASCII art lizard is much less appealing when all the lines are jumbled up, since the line breaks are displayed as "\n" instead, so it just wraps arbitrarily depending on your window's width.

Comment 3

[Mihai Sucan [:msucan]]

We had broken string output, if the string included quotes or backslashes. You could not copy/paste strings from JS output into a JS file without changes.

I agree it's not ideal - as you pointed out the ASCII art problem.

We can just revert the change (it would be a quick patch), if others also agree. Should we ping Victor/Benvie for a second opinion?

Comment 4

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

(In reply to Mihai Sucan [:msucan] from comment #3)
> We had broken string output, if the string included quotes or backslashes.
> You could not copy/paste strings from JS output into a JS file without
> changes.

Aha!  I missed that as the motivation, so thanks for explaining that. :)

> I agree it's not ideal - as you pointed out the ASCII art problem.
> 
> We can just revert the change (it would be a quick patch), if others also
> agree. Should we ping Victor/Benvie for a second opinion?

There have been times that I've wanted to copy strings, so I understand the motivation of the change, but generally I think the higher priority of output in the console should be that it's formatted for easy comprehension and understanding when reading quickly.  It takes away from that goal if line breaks aren't presented as actual line breaks.

Maybe we just revert, or maybe we could have "Copy as JavaScript" (or some other name...) in the context menu when you right-click on the string, to get a version usable in code?  That's really a new feature though I guess.  Just an idea.

Anyway, yes, let's get some other perspectives!

Comment 5

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

My gut feeling is that at least some special characters shouldn't be escaped, to allow pretty formatted output, ascii dragons and other forms of art. I love my \n to be newlines and \t to be tabs, but I wouldn't be too sad if other characters were escaped for reasons that I'm not smart enough to understand.

Comment 6

[Mihai Sucan [:msucan]]

Tested chrome's web console and firebug. Their behavior is as follows:

- when you eval JS and it returns a string, the string is wrapped around quotes, but no escaping happens.

- when you call console.log() a string, no quotes are used around the string. However, they use different colors, so you can tell the difference between 'null' and null, undefined, booleans, and numbers.

Sounds like we should do the same. We can do it in bug 584733

Here, as a quick 'fix', we can revert the string escaping.

Comment 9

[Simon Chan]

It might not because of bug in `console.log` function but the console itself.

For all Asian language characters, e.g. `"测试"`(test in Chinese), use `console.log("测试")` or only `"测试"`, both way will only print `"\u6D4B\u8BD5"`, in all old versions, or the way makes sense, it should be "测试" itself.

Which means, console had encoded all characters when printing.

Comment 10

[Brandon Benvie [:benvie]]

I think it's a reasonable expectation that someone using the console understands how escape characters work. I prefer escaping whitespace for three reasons: you often can't visually distinguish between various whitespace characters unescaped so you lose information, and whitespace has the ability to take up arbitrary vertical space so it can either break your UI or you have to hide the extra whitepace (losing information), and the ability to copy paste strings from the devtools to my editor without having to manually escape the string so it's valid JS.

Comment 11

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

(In reply to Brandon Benvie [:benvie] from comment #10)
> I think it's a reasonable expectation that someone using the console
> understands how escape characters work. I prefer escaping whitespace for
> three reasons: you often can't visually distinguish between various
> whitespace characters unescaped so you lose information, and whitespace has
> the ability to take up arbitrary vertical space so it can either break your
> UI or you have to hide the extra whitepace (losing information), and the
> ability to copy paste strings from the devtools to my editor without having
> to manually escape the string so it's valid JS.

This sounds like a valid use case, but I guess I am not convinced this is how console.log itself should behave, since it has already had an established method of working with special characters for quite some time, so it ends up changing the developer's assumption of how it works.

I've always thought of console.log as "dump to the console as if it were a terminal", so I would not expect to see the escaped characters.

Perhaps this desire is best served by a new console method intended for this purpose?

Comment 12

[Michael Cooper [:mythmon]]

Why is the goal of the console to product valid JS literals? I've never used the console in this way in any browser. Are there people who use the console to get JS literals? I know of several people who 

In bug 955873 I showed a screenshot of an error on the console from Angular.js in both Chrome and Firefox. Firefox's version is a lot harder to use because it printed newlines as \n instead of newlines, and Angular puts data on many lines to (try to) improve readability.

If distinguishing different kinds of whitespace is a goal, maybe it would be nice to have an option or button to show special characters like a lot of editors have the option to: putting small graphics where special characters exist, like this: http://www.akbarsait.com/blog/images//BP_CFBWhiteSpace.png

Comment 13

[Simon Chan]

Escaping characters makes it easy to know what characters printed, but no escaping can let us know what the output means more easily, I think most time we need the second one.

And as I say this problem happens on all console output not only `console.log`'s output, even use `decodeURIComponent("\u6D4B\u8BD5")` will also print `"\u6D4B\u8BD5"`, so what does `decodeURIComponent` do? It totally doesn't make sense.

Comment 14

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

If we feel that we should deviate from our or other browsers' established behavior, then we should probably discuss it more broadly by opening an issue here:

https://github.com/DeveloperToolsWG/console-object/

Comment 15

[Mihai Sucan [:msucan]]

I'm going to submit a patch here that reverts string escaping, to be more consistent with the other tools.

Comment 16

[Mihai Sucan [:msucan]]

Attachment: bug952708-1.diff

No string escaping, revert to previous behavior.

Try push: https://tbpl.mozilla.org/?tree=Try&rev=8eb1b968e66a

Comment 17

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

Comment on attachment 8356759 [details] [diff] [review]
bug952708-1.diff

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

LGTM.

Comment 18

[Ryan VanderMeulen [:RyanVM]]

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

Comment 19

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/ad1a0f745246

Comment 20

[[:Aleksej]]

Reproduced with 2014-01-08-03-02-03-mozilla-central-firefox-29.0a1.en-US.linux-x86_64.
WFM with 2014-01-09-03-02-03-mozilla-central-firefox-29.0a1.en-US.linux-x86_64.

Comment 22

[Rob Crowther]

> Why is the goal of the console to product valid JS literals? ... maybe it would be nice to have an
> option or button to show special characters like a lot of editors have the option to

As someone who today has been trying to use the developer tools to examine JS literals, did this suggested feature go anywhere?  I had a look at the issues on the GitHub repo but couldn't spot anything.

Comment 23

[Mihai Sucan [:msucan]]

(In reply to Rob Crowther from comment #22)
> > Why is the goal of the console to product valid JS literals? ... maybe it would be nice to have an
> > option or button to show special characters like a lot of editors have the option to
> 
> As someone who today has been trying to use the developer tools to examine
> JS literals, did this suggested feature go anywhere?  I had a look at the
> issues on the GitHub repo but couldn't spot anything.

Afaik no. Please feel free to open a bug report with the feature request.