Issue metadata
Sign in to add a comment
|
"i" icon missing on console.info output after new Chrome update.
Reported by
bitbey...@gmail.com,
Apr 21 2017
|
||||||||||||||||||||||
Issue descriptionUserAgent: 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 console.info. 2. 3. What is the expected behavior? I used to see an icon that was unique to console.info 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 console.info 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 console.info 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.
,
Apr 24 2017
Issue 714550 has been merged into this issue.
,
Apr 25 2017
Since [ Issue 714550 ](https://bugs.chromium.org/p/chromium/issues/detail?id=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.
,
Apr 25 2017
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.
,
Apr 25 2017
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 console.info - 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.
,
Apr 28 2017
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) :(
,
Apr 28 2017
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.
Ex:
console.debug('oldArr', arr, 'newArr', arr2);
With &c formatting, I can only get 'oldArr' to be blue.
Ex:
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! :)
,
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.
[1]: https://developers.google.com/web/tools/chrome-devtools/console/console-write#string_substitution_and_formatting
,
Apr 29 2017
Anyway, the new behavior does't seem an enhancement, it's rather confusing. >#1 pfeldman@chromium.org >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.
,
May 3 2017
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?
,
May 15 2017
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.
,
May 29 2017
Would this be fixed in chrome 59? This is what's holding me up from upgrading to chrome 58
,
Jun 1 2017
Yet another usecase of colored console.info I've determine application log (uses console.log) and my personal logs for debugging (uses console.info). It's helpful for visual determine these logs.
,
Jun 4 2017
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).
,
Jul 26 2017
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
,
Aug 10 2017
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.
,
Sep 5 2017
Please return old console.info() with icon, it was very handy.
,
Oct 4 2017
,
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.
,
Dec 26 2017
,
Nov 16
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 |
|||||||||||||||||||||||
Comment 1 by pfeldman@chromium.org
, Apr 21 2017We aligned severities across he system and both info and log fall into the info category. The reason we have console.info 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;", "");