New issue
Advanced search Search tips

Issue 714235 link

Starred by 18 users

Issue metadata

Status: WontFix
Closed: Oct 2017
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug-Regression

Sign in to add a comment

"i" icon missing on output after new Chrome update.

Reported by, Apr 21 2017

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.81 Safari/537.36

Steps to reproduce the problem:
1. Output anything to console using

What is the expected behavior?
I used to see an icon that was unique to output, this greatly assisted me in locating the line I was expecting. I often have to sort through dozens of lines of output in the console to find one that I'm using for troubleshooting, using made this much easier for me.

What went wrong?
Now, the line looks just like console.log output (nothing to distinguish it). Which begs the question, why even have anymore?

Did this work before? Yes 

Chrome version: 58.0.3029.81  Channel: stable
OS Version: OS X 10.12.4
Flash Version: 

Hope the "i" icon is returned, it's useful in ways most developers probably overlook.
Status: WontFix (was: Unconfirmed)
We aligned severities across he system and both info and log fall into the info category. The reason we have is to preserve backwards compat. I have two recommendations for you:

 - an obvious one that is get rid of spam or else you end up with spammy log and spammy info over time

 - a less obvious one

console.log("%ci%c Hello", "color: white; background: blue;", "");

 Issue 714550  has been merged into this issue.
Since [ Issue 714550 ]( has been merged into this one, I will add the important points from there. Maybe it will change the WontFix status:

Not only the info option is missing, but also the debug one. console.debug is what we developers use when we want to debug our code, and is the standard for react environment logging. Now, we can either work with the info channel, where the debug doesn't appear, or we have to work with the verbose channel, where we see all the logs.

And, by the way, these logs are not spam. They are what we want our app to print out so we can know what's going on. But it is not the same as the debug logs.
Status: Assigned (was: WontFix)
Thanks for posting additional notes here. Could you clarify whether you are using console/debug/info/log for filtering or for visually distinguishable log entries? You can decorate log entries using %c and you can still have multiple levels (warning/info/verbose), so I'd like to better understand what is missing.
We are using the debug/info/log for filtering:
- Our app continuously logs events that help us debug our live app on a customers pc. For this we are using
- While developing, we sometimes want to print out different things to the console. Since we don't want these to get lost in all the other log, we use for this console.log
- We also have a third type of logging - for performance checks. For this we use  the console.time and console.timeEnd functions. Up until now these would be printed to the debug channel.

So, as you can, we made use of all three channels.
I've been using console.debug for years to differentiate between development consoles and consoles we want to leave in for production (which we do still want to leave in) -- both to visually distinguish log entries and to filter out what's being seen in the console. This recent change is really bumming me out. Please consider changing it back, including changing the debug format back to blue text. It was super useful as it was, and now it's kind of worthless.

(I recognize I can format individual log entries, but a built-in standard formatting for an entire category was really helpful) :( 
I spent some time trying out %c formatting to get my console.debugs back to blue. Unless I'm missing something, it looks like this formatting only works on a single string at the beginning of a console statement, whereas the previous behavior printed all strings in the arguments blue. 

console.debug('oldArr', arr, 'newArr', arr2);

With &c formatting, I can only get 'oldArr' to be blue. 

console.debug(arr, 'changed to', arr2);

With %c formatting, there's no way to format the 'changed to' string.

Additionally, I tried rolling my own devtools theme extension, and it looks like (again unless I'm missing something) there's no class that targets console.debug statements -- only info (which includes info and log, so not helpful towards the goal of differentiatiating the two), warn, and error.

Looks like there's no real workaround, so hoping the previous builtin formatting is coming back! :)

Comment 8 by, Apr 29 2017

#7, use %o, %O and other format specifiers [1] inside the first string to make %c apply to the entire range of parameters, for example:

console.debug('%coldArr %o newArr %o', 'color:hsl(220, 100%, 65%)', [], [1,2,3]);

Actually, you can make a wrapper that overrides console.debug and constructs the correct format string by inserting %o and other applicable specifiers in place for each argument according to its type.


Comment 9 by, Apr 29 2017

Anyway, the new behavior does't seem an enhancement, it's rather confusing.

>We aligned severities across he system and both info and log fall into the info category

Those "alignments" also destroyed individually selectable log levels in console filter.
How does it align with us, the developers, the users? 
Doesn't seem to align at all.
Seems like a designer's whim.
Dear Chrome people,
Before we start working on some workaround hack to solve this issue, we would like to know - are you planning to fix this soon?
I have created #722152 to do with the loss of the ability to select a combination of filters for view. 
I believe this ticket would need to be fixed for #722152 to be very useful.

Comment 12 by, May 29 2017

Would this be fixed in chrome 59?
This is what's holding me up from upgrading to chrome 58
Yet another usecase of colored
I've determine application log (uses console.log) and my personal logs for debugging (uses
It's helpful for visual determine these logs.
Indeed, it became harder for us to debug our applications. Can't we have a separate console for logging outside our own code (browser warnings, extensions).
This bug also occurs on windows machines.

UA: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36
When will this design defect be fixed. It's pretty clear the new design removes useful (some might say vital) functionality. In fact, I challenge you to find a single developer (outside of the chrome team) who thinks this was a good idea.
Please return old with icon, it was very handy.
Status: WontFix (was: Assigned)

Comment 19 by, Nov 13 2017

I'm not upgrading chrome because I don't like this new change.
I here from colleagues that it's very annoying to develop and debug with logs since this change in chrome.
Please fix it.
 Issue 797578  has been merged into this issue.
I can't believe this has been open since April 2017 and is marked as won't fix. It's so obvious that people have real use cases for separating two levels of logs that are not warn or error, one as a catch-all give-me-all-you-have, and one for give-me-the-gist. This is not just about visual appearance, it's about being able to filter by levels. So many people here expressed that this was a bad change. Who ever _complained_ about having a dedicated info level?! How does it hurt?!

Sign in to add a comment