What happened to the Developer Tools console?

[Heath Bishop]

As a web developer I am constantly using chrome's Developer Tools.  But now it's impossible to use the Console. What possible logic led you to believe that switching the display selections (All, Errors, Warnings, Info, Logs, Debug) to a drop down was a good idea?  First of all, where is Logs in the drop down?  How can I select Errors and Logs at the same time?  Were developers even asked if this was a desired change?  This is very disappointing.  Especially for a browser that prides itself in usability.

Time to give Firefox or Vivaldi another look.

[Pavel Feldman]

If you select Log, you see errors. The drop down configures the verbosity filter like in pretty much all loggng systems...

On Wed, Apr 26, 2017, 13:48 Heath Bishop <heat...@gmail.com> wrote:

As a web developer I am constantly using chrome's Developer Tools.  But now it's impossible to use the Console. What possible logic led you to believe that switching the display selections (All, Errors, Warnings, Info, Logs, Debug) to a drop down was a good idea?  First of all, where is Logs in the drop down?  How can I select Errors and Logs at the same time?  Were developers even asked if this was a desired change?  This is very disappointing.  Especially for a browser that prides itself in usability.

Time to give Firefox or Vivaldi another look.

--
You received this message because you are subscribed to the Google Groups "Google Chrome Developer Tools" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-chrome-develo...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-chrome-developer-tools/7b8bc885-5cdd-4dae-8179-a025ee957b3d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[PhistucK]

It is a bit funny, because the old multiple concurrent filters feature was added because developers requested it (it was not there originally). Why made you conclude that it is not necessary (other than the fact that other logging systems or user interfaces do not provide that)?

☆PhistucK

On Wed, Apr 26, 2017 at 11:53 PM, Pavel Feldman <pfel...@chromium.org> wrote:

If you select Log, you see errors. The drop down configures the verbosity filter like in pretty much all loggng systems...

On Wed, Apr 26, 2017, 13:48 Heath Bishop <heat...@gmail.com> wrote:

As a web developer I am constantly using chrome's Developer Tools.  But now it's impossible to use the Console. What possible logic led you to believe that switching the display selections (All, Errors, Warnings, Info, Logs, Debug) to a drop down was a good idea?  First of all, where is Logs in the drop down?  How can I select Errors and Logs at the same time?  Were developers even asked if this was a desired change?  This is very disappointing.  Especially for a browser that prides itself in usability.

Time to give Firefox or Vivaldi another look.

--
You received this message because you are subscribed to the Google Groups "Google Chrome Developer Tools" group.

To unsubscribe from this group and stop receiving emails from it, send an email to google-chrome-developer-tools+unsub...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-chrome-developer-tools/7b8bc885-5cdd-4dae-8179-a025ee957b3d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Google Chrome Developer Tools" group.

To unsubscribe from this group and stop receiving emails from it, send an email to google-chrome-developer-tools+unsub...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-chrome-developer-tools/CAEX3KhYhajkY2rZ9997r_wubr0KhwkTQoCqSWJ4etY%3D_pX5pZA%40mail.gmail.com.

[davidm...@thebettersoftwarecompany.com]

Chrome DevTools console no longer can filter out errors?

This was not a smart change. I'm quite disappointed. I use this console every day, and now every single red error is displayed and I can't change between logs and info... Please change this back, or allow us to customize. Impossible to view logs or info with errors and warnings clogging up the console...

[Heath Bishop]

Select Log?  Where in the console tab can you select Log?  The old way allowed you to select Logs so you can see console.log() found in the code.  There is no such option now.

This is starting to remind me of the ie days where MS told developers what they can and can't do.

[Dante Federici]

Seconding this -- the decision to change the filter on the devtools to a vague dropdown was terrible.

On Wednesday, April 26, 2017 at 4:48:12 PM UTC-4, Heath Bishop wrote:

[RaphaelDDL]

I'd like to say that I've (not) been using this select for a while since I use Canary daily. 

Really wasn't the best thing. I like that it's an instant filter but not having log only or not enabling some kind of mix as the filters elsewhere allows (as the previous one) was.. annoying.

[harry...@gmail.com]

This is an insane decision that essentially renders Chrome useless for debugging.

[sirm...@gmail.com]

Just joining in to voice the same opinion - this decision to remove this tiny but extremely useful feature was insane. As a web developer, I am all but forced to look for a new browser for my day-to-day work, because I can't possibly get anything done in this large project without the ability to filter warnings, logs and debugs on and off.

[mar...@biddl.com]

Just chiming in that this is a change that was not requested or wanted. It renders the logging system entirely useless for the purpose I personally use it the most, i.e. quick debugging. Trying to differentiate log and debug now seems impossible and no I'm not going to spend hours trying to figure out how this shit is going to work, I have more important things to do, thanks Google. Would downgrade, but in their infinite wisdom Google has made even that difficult. All I can right now say is a great big THANKS. (and yes, I'm reverting to sarcasm, that's just how pissed I am.)

On Wednesday, April 26, 2017 at 11:48:12 PM UTC+3, Heath Bishop wrote:

[Giovanni Piller Cottrer]

Hi pfeldman,

I see your point, but many of us here, especially in development environments, often need to filter out everything but very specific kinds of log messages.
The larger the application, the more useful these filters are.

We don't always have control on the console output, like when you're including third party code/resources.

As a matter of fact, I often have the console filled with Errors & Warning which I cannot possibly fix, or are not relevant to my current task.

Other times, the console is filled with useful `console.log()` from the application, but I need to temporarily focus on your sub-component's `console.info()`.

On top of that, this behaviour is now unique to Chrome. Every other browser allows greater flexibility.

[Neville Gallimore]

Please revert these changes for the "New Console UI" in Chrom 57. Sorry, but these changes are terrible and counter productive for most scenarios.

[Pavel Feldman]

It seems like the issue most are struggling with is that in certain test/staging environments, console is flooded with network/video stream errors and it is hard to see your own logs. We would not want actual JS errors to be filtered out in that workflow though. 

How about we add a checkbox filter saying "Show only JS errors and messages produced with console.* calls"? Will that address most of the concerns? I.e. are you actually trying to see console.* messages and due to the lack of a better option use level filter for that?

On Tue, May 2, 2017, 13:06 Neville Gallimore <neville....@gmail.com> wrote:

Please revert these changes for the "New Console UI" in Chrom 57. Sorry, but these changes are terrible and counter productive for most scenarios.

--

You received this message because you are subscribed to the Google Groups "Google Chrome Developer Tools" group.

To unsubscribe from this group and stop receiving emails from it, send an email to google-chrome-develo...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-chrome-developer-tools/edb9bc59-0c81-4d63-a78e-e584022acc86%40googlegroups.com.

[Dmac]

Why was this change made in the first place? It was working wonderfully the way it was. 
I understand if it was a case of 'just getting used to the new' as how many complain when anything new comes out, but this fundamentally ruined how most people are using the console.
Why would we not want to filter out errors and warnings? Many times errors are thrown by another dev's code which we do not want to see. We also want to separate the console.logs from the console.infos 

It's important to be able to see our logs as cleanly as possible, otherwise we're wasting an incredible amount of time trying to find our logs vs the infos vs the warnings and errors.

[Kayce Basques]

From a UI perspective, I like the new dropdown. Less clutter. To get the best of both worlds, how about this:

• Click to expand the dropdown.
  
• Each option in the dropdown is a checkbox, letting you select multiple filters at once.
  
• DevTools exposes a setting that lets you pick whether you want the higher-level categories (the most recent UI) or the line-item-level categories (the way it used to be). I don't know which one should be the default.

[Kayce Basques]

I also think a checkbox approach is more intuitive to first-time users. Having to hold shift to select multiple filters was a bit obscure

[Giovanni Piller Cottrer]

How about we add a checkbox filter saying "Show only JS errors and messages produced with console.* calls"? Will that address most of the concerns? I.e. are you actually trying to see console.* messages and due to the lack of a better option use level filter for that?

 

That would certainly improve the situation, but only a bit.

A use case that I often see is differentiating console.log (application's debug information) from console.info (component's debug information, or the thing you're working on).
There are many situations in which the console is filled with console.log/warnings/errors, but you need to pinpoint a specific kind of message.

On Wednesday, May 3, 2017 at 4:03:46 PM UTC+2, pfeldman wrote:

It seems like the issue most are struggling with is that in certain test/staging environments, console is flooded with network/video stream errors and it is hard to see your own logs. We would not want actual JS errors to be filtered out in that workflow though. 

How about we add a checkbox filter saying "Show only JS errors and messages produced with console.* calls"? Will that address most of the concerns? I.e. are you actually trying to see console.* messages and due to the lack of a better option use level filter for that?

On Tue, May 2, 2017, 13:06 Neville Gallimore <neville....@gmail.com> wrote:

Please revert these changes for the "New Console UI" in Chrom 57. Sorry, but these changes are terrible and counter productive for most scenarios.

--
You received this message because you are subscribed to the Google Groups "Google Chrome Developer Tools" group.

To unsubscribe from this group and stop receiving emails from it, send an email to google-chrome-developer-tools+unsub...@googlegroups.com.

[Kane York]

What about adding a searchable tag to the start of your messages?

console.info("[TAG] items in queue: " + q.length);

Then pop the [TAG] in the search bar and it's filtered to just the component you're working on.

[Dmac]

But why should the developer be expected to do this to poorly replicate a feature that was already there? It was working perfectly the way it was before. What possible benefits are we getting with the new design? This would just add an extra 30 seconds every time we need to add a log and search for it. 
First of all, its now 2 clicks per toggle. Second, the toggle values are extremely vague. Third, the functionality has completely changed removing incredibly useful features. 

[Heath Bishop]

This seems more like a hack, than a fix.
Ultimately the problem is this feature was removed when it shouldn't of been.  The purpose of UI simplification should be to add more functionality without making the UI more complicated.  Not to remove functionality.

[Heath Bishop]

It would really be nice if Chrome would go the same route as the console in Firefox Developer.  Where there are drop-down menus with multiple options to filter out Net, CSS, JS, Security, Logging, and Server.  And you can select as many as you want.

[RaphaelDDL]

@Kayce

Yup, less clutter, I agree. But isn't good.

Imagine how this filter with "best of both" would look like (and how much vertical screen space would take) if you are to apply it on the Network filter. The console and network had same filter UI, makes no sense to change one but not another, it's bad UX. But I don't think Network would be good like that.

I really like current Network filter (which was console's). It is toggleable (so you can same few pixels in screen space), you can hold CMD (in Mac) and click on the options to have more-than-one filter.

By the way, we need a "Verbose (Light)" which hide these [Violation] lol. 

[glenn.a...@symphony.com]

The issue most are struggling with is the loss of useful functionality. This is the cardinal rule of software, don't remove functionality. The software, in this respect, has been made worse. The best way to address this is to put back the old functionality. 

I don't see the issue here. Somebody made a poor choice to remove functionality. The solution is to restore the old feature. Lesson learned. 

On Wednesday, May 3, 2017 at 7:03:46 AM UTC-7, pfeldman wrote:

It seems like the issue most are struggling with is that in certain test/staging environments, console is flooded with network/video stream errors and it is hard to see your own logs. We would not want actual JS errors to be filtered out in that workflow though. 

How about we add a checkbox filter saying "Show only JS errors and messages produced with console.* calls"? Will that address most of the concerns? I.e. are you actually trying to see console.* messages and due to the lack of a better option use level filter for that?

On Tue, May 2, 2017, 13:06 Neville Gallimore <neville....@gmail.com> wrote:

Please revert these changes for the "New Console UI" in Chrom 57. Sorry, but these changes are terrible and counter productive for most scenarios.

--
You received this message because you are subscribed to the Google Groups "Google Chrome Developer Tools" group.

To unsubscribe from this group and stop receiving emails from it, send an email to google-chrome-developer-tools+unsub...@googlegroups.com.

[cyc...@gmail.com]

Yeah, For filter console.log, I have chosen firefox.  

[Zac Spitzer]

please revert this change, it's very frustrating

[block...@gmail.com]

Having to hold shift to select multiple filters was a bit obscure

Don't agree with that, after all, this is how selecting non-consecutive items works in the file systems of most OS GUIs.

a checkbox approach is more intuitive to first-time users

Do agree with this. I like the multi-select drop down idea, so long as the options are those that we had previously i.e. 'warnings, logs, errors' etc.
And maybe an option in settings to move to the new, less configurable filter system. 

The drop down configures the verbosity filter like in pretty much all logging systems

The logging systems you refer to are most likely those that print to stdout and not ones that are part of a large GUI interface as is the case here.
A move towards consistency is good so long as we're moving in the right direction. The old setup allowed much more user control and was therefore more usable.
Other logging systems should have been trying to emulate Chrome, not the other way around. 

No matter how the interface changes I would like to implore the developers at Chrome to move back to the old style of filtering as I (and I'm obviously not alone here) find the new filtering setup much harder to use. Far too much noise when looking for log statements etc.

[s.ch...@gmail.com]

I also wish you could revert this change. 

When debugging, having the possibility to filter errors, logs, warning, info, (...) is a must. 

Right now, the time I spend debugging has slightly increased because the log console is completely cluttered.

[Ivan Voznyakovsky]

Totally agree that this new console filters are just USELESS. Now I'm forced to add a namespace to all my console.logs and filter on it. Hate this new filters. They make me hate the tool I used to love to work with. Do not become another IE, hear the users.

среда, 26 апреля 2017 г., 23:48:12 UTC+3 пользователь Heath Bishop написал:

[Viktor Zozuliak]

I must say that I also don't like the new behavior. I'd vote for reverting the old one.

середа, 26 квітня 2017 р. 22:48:12 UTC+2 користувач Heath Bishop написав:

[Heath Bishop]

A bug was logged at https://bugs.chromium.org/p/chromium/issues/detail?id=717776#.

Please Log in and star the bug to let the Chrome developers know how important this is.

[Jason Edelman]

I need to chime in here too. I can't fathom how anyone decided this was a good change. The answer of "just namespace your stuff and search for it" is akin to Steve Jobs telling people they were holding the phone wrong. Also, if you have thousands of warnings or error messages (which can happen when you're working in a big framework that, say, you just updated and is now alerting you of thousands of deprecations), trying to filter in the search box basically crashes dev tools.

This "levels" concept is absurd. If I want to see "levels" I'll check off the things I want to see. Sometimes I'd prefer to only see logs and nothing else. Or errors and nothing else. Or warnings and nothing else. Very rarely, if ever, do I want to see info + warning + error. From the volume of complaints here, it seems like I'm not alone. 

Please revert this short-sighted change ASAP.

Thanks.

[cyc...@gmail.com]

please please please please please revert this change, it's very frustrating, I just need console.log not console.info or any chrome-extension info.

[Cory Danielson]

I agree. Also not a fan of the new console changes. I'm not sure why console.debug was removed. I used it often as a personal console during development, because libraries can spam into warnings/errors/log. I'd just recently started to use multi-select to view warnings + errors, or log + debug. The dropdown feels like a step back in UX

[sirm...@gmail.com]

Just posting to let anyone who cares at Google know that this still hinders my work on a daily basis. 

If I wanted to turn Chrome into the next Internet Explorer, this is the sort of change I'd make. Just a tiny little thing with no reason behind it to drive away devs. 

[Paul Irish]

Thanks everyone for sharing their thoughts here. We're open to changing how the console filter works, but we need some more information.

Can I get a few more specifics on how've been using the console filters?

For example, I heard Cory above indicate he used console.debug() so he could filter to Debug and ignore all the other logs/errors happening.

David mentioned that errors/warnings are already clogging up the console and he needs to focus on logs. 

One particular followup question I have is.. what are these errors & warnings and why are they being kept? Are they network failures from adblocker, are they coming from third party scripts that you can't control?

[Viktor Zozuliak]

Hi, Paul!

I think it is not really important from where all these errors/logs/warnings are coming. The main thing is that now we can't see just errors or just logs or just warnings, or any combination of types we were able to define before. We now have predefined combinations and we stuck with it. The predefined combinations are:

- Errors - only errors

- Warnings - errors + warnings

- Info - errors + warnings + info

- Verbose - errors + warnings + info + logs

What if we need only logs? Or only warnings? We don't have this option anymore. It is definitely a regression.

понеділок, 15 травня 2017 р. 17:42:10 UTC+2 користувач Paul Irish написав:

[Heath Bishop]

I use console.log(), console.debug(), and errors for JavaScript, logging, and security.  I would really love it if CSS errors and warnings were added.

[Paul Irish]

> I think it is not really important from where all these errors/logs/warnings are coming

Well, it'd be very important if they are emitted from the browser (about document.write or Sync XHR), because then it's Chrome's responsibility to make the console less noisy.  

Also it's interesting to know if many are of the same type and perhaps they should be grouped better?

> What if we need only logs? Or only warnings? We don't have this option anymore. It is definitely a regression.

Oh I totally get that. I understand the regression in functionality here. I'm just trying to get a handle on specific usecases so we can make sure we can support them.

--
You received this message because you are subscribed to the Google Groups "Google Chrome Developer Tools" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-chrome-developer-tools+unsub...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-chrome-developer-tools/180c2d26-7f29-44a9-83fb-636c4ebcf777%40googlegroups.com.

[Dante Federici]

Thanks for seeing this!

Most of my code abstracts the logging service away. But, for local development, it acts as a simple pass-through to the console methods (.log, ,warn, .info, .error, and .debug), which is VERY useful for interactive debugging.

In general, I've used `console.debug` during development to track my own state, while debugging, etc. It's useful to explore objects in the console. Some developers use `console.log` for this purpose as well. I use `debug` for the explicit purpose of easy filtering, and I generally remove all debug statements once the code is working and tested.

`console.log` and `console.info` are generally interchangeable from my use / other developers I work with -- useful information by whatever system or service you're making (anything that normally goes to stdout, things like init state, connection logs, etc.).

`console.warn` also sticks around in code, and is used to flag assumptions on bad input, or deprecated usages.

Finally, `console.error` is nice for the stack trace and as a way to give more color around an error without having to use an explicit error object (as a developer, I might want more context, or at a switch default where I can return an "empty" result, but flag an unhandled case).

In general, the `console.` are great for local development and ad-hoc work/debugging.

The reason this change bothers me is it only serves to reduce the filtering options I had prior. It's also important to note that *other libraries* use console statements outside of production (sometimes), and with the addition of Chrome itself logging to the console, it has become much more annoying to deal with. Lots of front end tools like Webpack's dev server, Redux's logger, etc. push to the console. Making assumptions for how an individual dev uses the console definitely helps understand how to design the filtering, but the problem is when you combine random devs with different ways of logging, you need to be able to specify some pretty specific filters in most cases.

Sidebar:

While I'm here, it is VERY obnoxious that the filter string doesn't filter on the label for grouped console messages.

[Paul Irish]

On Mon, May 15, 2017 at 9:02 AM, Dante Federici <c.dante....@gmail.com> wrote:

 I use `debug` for the explicit purpose of easy filtering, and I generally remove all debug statements once the code is working and tested.

Cool. TBH, I've never known about this trick. Seems useful with a busy console.

 

It's also important to note that *other libraries* use console statements outside of production (sometimes), and with the addition of Chrome itself logging to the console, it has become much more annoying to deal with. Lots of front end tools like Webpack's dev server, Redux's logger, etc. push to the console.

Gotcha. That's useful. Would you mind posting a screenshot or two of your console when it's busy like this?

 

Sidebar:

While I'm here, it is VERY obnoxious that the filter string doesn't filter on the label for grouped console messages.

Aye. Known issue that's tracked here: 363796 - ☂ Console filter inappropriately hides grouped content and doesn't hide group titles - chromium

 

[Cory Danielson]

I work on a huge codebase where console.log has been used to publish deprecation notices as well just garbage. We also have a few ways to enable logging of Backbone objects and pub/sub system that use console.log. Because of all that, I avoid console.log. Warn/error are dominated by 3rd party libraries (React mainly). debug/info have become the only console methods I can use, and easily find the statements that I am logging. The new console filter also helps with this, though, but I have to add a common string to all the logging that I'm temporarily adding.

I also don't know the motivation for changing the UX. After view source, the console is likely the 2nd dev tool that any front-end web dev started to use. It's become very familiar and we've all developed workflows around it's consistent UX. That UX changed, and we all have to adapt to a system that gives us less control. It feels like an "It's not broken, don't fix it" kind of situation.

On Monday, May 15, 2017 at 10:42:10 AM UTC-5, Paul Irish wrote:

[Dante Federici]

Certainly -- Here's a screenshot of some logs during runtime.   -- this is on verbose:

Things to note:

• looks like the grouping CSS style is inline, which is just unnecessary noise
  
• Chrome violations from 3 different libraries (d3-selection, autocomplete, and angular)
• Console warnings from 1 library (localforrage)
• Errors from my own code, within angular
• Errors from my own code (ExploreComponent)
• Regular kitchen-sink info logs from redux (router5middleware)

This is without ANY of my own debugging logs. Log groups not being filtered EXTREMELY over complicates this problem, but as you pointed out, separate issue.

In production, many of those kitchen sink logs are represented by info, warn, log, and error instead of groups.

[chang...@gmail.com]

So is there a way to only see console.debug() outputs besides prepending the output string with keywords?

[Wojciech Zieliński]

Very wrong decision.
So we have to make dirty hacks for dev tools, to make dev tools usable again... 

Fast & drity hack/fix, to be less angry:

const { warn, log, error, info } = console

const $flags = {

  warn: false,

  log: false,

  error: false,

  info: false,

}

console.warn = ( ...args ) => { $flags.warn && warn( ...args )  }

console.log = ( ...args ) => { $flags.log && log( ...args )  }

console.error = ( ...args ) => { $flags.error && error( ...args )  }

console.info = ( ...args ) => { $flags.info && info( ...args )  }

window.$setConsoleFilter = ( flag, value ) => $flags[flag] = value

window.$toggleConsoleFilter = ( flag ) => window.$setConsoleFilter( flag, !$flags[flag])

[maarten....@sorama.eu]

I'm +1-ning this. The buttons where first removed from Opera's console, it was unworkable, now Chrome deletes them too? I'm also very frustrated that something i use and need every day just changes without notice. Please bring back the old buttons, and for the people who like the dropdown (which is always 1 click more which in and on itself is frustrating) make it an options to chose between the new dropdown and the old multiple filters buttons.

[Dmac]

Just noticed there was a commit to "fix" this issue on the linked ticket 

Chromium Devs, this does not fix the issue. There is still a massive regression in filtering out console.log from console.debug and console.info
There still has been no public response despite hundreds of people expressing their displeasure on the feature announcement page, on reddit, on stack overflow, and in this forum.

Why are you fighting the developers? Why are you removing this functionality?

Please bring back the old functionality the way it was, not in a limited way just to get people to shut up....

[PhistucK]

I also agree. A select box with check boxes is the right way to go here. Please, allow the users of the Developer Tools feature to choose what to show, whether it is a single level, or multiple specific ones.

As an aside, "Show user messages" is a highly misleading and unintuitive description. Console API messages are definitely not "user" messages, they are developer and/or author and/or library messages. Basically, everything but user messages.

☆PhistucK

--

You received this message because you are subscribed to the Google Groups "Google Chrome Developer Tools" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-chrome-developer-tools+unsub...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-chrome-developer-tools/3ed900ce-f112-4386-b776-c55765b5e6fc%40googlegroups.com.

[Autumn Fjeld]

+1

 

Please allow customization of console message as in previous versions:

That image taken from chrome-devtools out-of-date docs:  https://developers.google.com/web/tools/chrome-devtools/console/

On Wednesday, May 24, 2017 at 8:28:53 AM UTC-7, PhistucK wrote:

I also agree. A select box with check boxes is the right way to go here. Please, allow the users of the Developer Tools feature to choose what to show, whether it is a single level, or multiple specific ones.

As an aside, "Show user messages" is a highly misleading and unintuitive description. Console API messages are definitely not "user" messages, they are developer and/or author and/or library messages. Basically, everything but user messages.

☆PhistucK

[Heath Bishop]

I still think that when it comes to the developer tools, the more options, the better.  Especially when you consider that the developer tools are not used by your average user.  Their used by developers who are deep into the code.  There is absolutely no reason to dumb the developer tools down.  If Chromium's goal is to make the browser more user friendly for everyone, then maybe they should take a tip from Firefox and create a developer version for developers and a dumbed-down version for everyone else.  This is the reason the console in the Developer Tools in the Firefox Developer Edition is superior to the console in Chrome's developer tools.

See the comparison below.

Firefox Developer Edition: developer tools console.  Many drop-down filter options where you can select as many or as few as you want at the same time.

Chrome: developer tools console.  Um.. A filter and a drop-down that only allows you to select one option.

[Ken Stanley]

+1 for reverting this new "feature" back to its original usage. 

Some questions I hope Google could answer for us devs:

1. What makes selecting pre-defined options more flexible than being able to mix-n-match verbosity using toggle switches? 

2. Why did you remove the Hide Violations checkbox?

It seems to me that for some unknown reason, the folks at Google are Hell-bent on getting rid of the toggle switches for log levels and replacing it with the pre-defined list of log levels. Change for the sake of change I guess. If that's the case, fine, not much us pleeb developers can really do to change your minds. However, I would like to offer a compromise: if you're going to keep the pre-defined list, would you at least extend us an olive branch and give us the ability to add custom filters of our choosing? I envision it could work just like the Emulated Devices works where it would allow individual developers to define their own custom filters. It would move this customization out of the main console window (which I presume was your intended goal), without removing the flexibility the old UI offered.

Image for reference: http://i.imgur.com/pPhzgVt.png

To be honest though, I'd prefer the old UI over anything else. It was easy and intuitive. Now it's confusing, frustrating, and to echo the sentiment of others in this thread: infuriating.

Thank you.

On Monday, May 15, 2017 at 11:42:10 AM UTC-4, Paul Irish wrote:

[Kayce Basques]

Here's a message from the DevTools team:

Our change to the console was intended to align with the conservative log levels model (verbose, info, warning and error). It is important for console to serve other domains such as network, rendering, interventions, etc in a consistent manner.

As a side effect of the new model adoption, console.log and console.info both fell into the same info level. We did not expect this to negatively impact your productivity - console.info usage was considered to be very low.

We also did not expect users to explicitly filter out warnings and errors from their console, but we now understand there are legit use cases where it comes in handy: CORS errors, media stream errors, etc.

We believe that there is a better solution to filtering out console spam and focusing on your console.* messages. We've exposed a only show Console API messages option as an experiment to see if that resolves the issue for you. Please give it a try and let us know how it worked for you. If it did not, we’ll keep working on figuring it out.

Thank you for your patience!

[Dmac]

Dear Kayce and DevTools team.

Thank you for the response, this is appreciated.
As noted in previous replies:
"... this does not fix the issue. There is still a massive regression in filtering out console.log from console.debug and console.info"

There has still been no reason for why it was changed to " align with the conservative log levels model (verbose, info, warning and error)"
What benefit does this give other than 'consistency' and 'conservatism' for the sake of itself?

How does this update make things more "consistent" and more able to service "other domains" than the firefox model posted above?

"We also did not expect users to explicitly filter out warnings and errors from their console"

To be honest, this tells me that the update itself was not to make the user experience better based on actual research of how the console is being used, but simply as a way to "clean things up" and make it more like other logging tools. 

Showing user only logs is a small step, but we're now still limited to a single channel rather than the legitimate multi-channel use cases mentioned in this thread. 

Please reconsider your decisions. 

Thank you.

[Ken Stanley]

On Thursday, June 1, 2017 at 10:48:57 AM UTC-4, Kayce Basques wrote:

Here's a message from the DevTools team:

Our change to the console was intended to align with the conservative log levels model (verbose, info, warning and error). It is important for console to serve other domains such as network, rendering, interventions, etc in a consistent manner.

What does that mean? I tried googling "conservative log levels model" and it doesn't seem to be a wide-spread model (or is it an internal Google-only model?). It might help if we had some more context as to what you're trying to achieve.

 

As a side effect of the new model adoption, console.log and console.info both fell into the same info level. We did not expect this to negatively impact your productivity - console.info usage was considered to be very low.

We also did not expect users to explicitly filter out warnings and errors from their console, but we now understand there are legit use cases where it comes in handy: CORS errors, media stream errors, etc.

Why wouldn't you have expected that? Pardon me for sounding sardonic, but have the people making this decision never developed web pages before? I mean that in a genial way; whenever you work with third-party libraries, it is common (especially in a development environment) to see a lot of different messages/errors/warnings/info/debug/etc. 

 

We believe that there is a better solution to filtering out console spam and focusing on your console.* messages. We've exposed a only show Console API messages option as an experiment to see if that resolves the issue for you. Please give it a try and let us know how it worked for you. If it did not, we’ll keep working on figuring it out.

This wouldn't solve the problem at all. This would only toggle Chrome-specific messages. Third-party user-land libraries that use the console.* API would not be affected, and there would be no way to filter them. There is no standard for when to use debug, info, warn, etc, so it's whatever is the whim of the particular library developer. Even if there were a standard, that doesn't mean people would a) know about it, and 2) follow it.

Having those log level toggles, the Show Network and Hide Violations checkboxes were the "better solution" to begin with. What was so broken about that model that it needs to be streamlined? 

[Viktor Zozuliak]

I am confused. 

Why not just giving back people the way to flexibly adjust types of console messages being displayed? 

Having this ability everybody can tune whatever level they want. Now everybody is stuck with pre-defined levels with no ability of flexible tuning. What was wrong with previous model?

четвер, 1 червня 2017 р. 16:48:57 UTC+2 користувач Kayce Basques написав:

[PhistucK]

While it might not be a strong argument (and it has been stated before, I believe), all of the other browsers support showing multiple specific types of logs (previous Chrome and Firefox are the only ones that differentiate console.log from console.info, though). Visual Studio also lets you select multiple log types. I do not understand the rationale for removing this feature. Especially the "we did not expect" part - you have use counters or user metrics analysis for that.

The way I see it - unless it is a maintenance nightmare, the Developer Tools feature cannot have enough too many (generic) features. It is just a matter of displaying them uncluttered, rather than removing features altogether.

☆PhistucK

--

You received this message because you are subscribed to the Google Groups "Google Chrome Developer Tools" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-chrome-developer-tools+unsub...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-chrome-developer-tools/4196bd50-c5ce-4c4a-94ed-b547249a2567%40googlegroups.com.

[Heath Bishop]

The DevTools team must of forgotten that JavaScript is not a strongly typed language, which can make it very difficult to debug at times.  Start adding third party libraries and frameworks and the difficulty multiplies.  Because of this, the "conservative log levels model" isn't enough!

Before you start talking about tools we can add to make this easier, I'd like to remind you that not all of us have the luxury of choosing what frameworks and libraries we get to use.

Maybe a happy middle would be to add an advanced developer mode that we can turn on in the Developer Tools settings.

[王湋之]

I have to face 7k + warning 1k + error to digging my log message. I have to additional flag to log messages in order to filter them out, and the best part is, filtering through 8K+ console entries takes forever and sometimes the dev tool will just crash....

[Alun]

For me, I want to be able to see info level without also having to see errors and warnings. This as far as I can see is now impossible.

[Kayce Basques]

Sorry, my last response had a lot of corporatespeak. Let me discuss this further in normal-people-language

I'm going to try to give you more insight on the DevTools' team's perspective. I'm not speaking on behalf of the team right now, just my own understanding of the conversations we've been having. So I may not be representing my teammate's views completely accurately. Here it goes:

It's important to keep in mind that DevTools has a responsibility towards maintaining the health of the web. Ideally, we want to push the web forward in a faster, more secure, more enjoyable, direction, etc. This goal drives the design of DevTools.

With this in mind, the ability to filter out errors in the Console is kinda suspect. Ideally, when you get an error, the solution is to fix the cause of the error, not just filter it out. This is part of why the DevTools UI switched to the new "severity level" dropdown menu. Being able to filter out errors is kinda like a car manufacture giving you the option to turn off the "engine needs service" messages that you get on your dashboard. This is also what we meant when talking about getting the DevTools model inline with other logging models. It's not common to be able to filter out errors in other logging models.

This whole topic has kicked off a much broader discussion on the state of logging in general. For example, we've started discussing all of the system messages that other parts of Chrome logs to the DevTools Console. Maybe we need to put pressure on them to stop spamming the Console. Or maybe we need to restructure how these messages get displayed. There's lots of possibilities. Personally, I've got to say that I'm impressed with the DevTools' engineers willingness to challenge the status quo in order to think up better solutions.

In terms of what to do, I suggest the workflow of adding some unique text to your logs and then using the text box filter to isolate those messages. Somebody said that the workflow breaks down when you have thousands of messages, so the team might need to look into that. But then again, I'm going to have to challenge that person and ask, why do you have thousands of messages getting logged? Maybe you need to put some pressure on the third-parties that are dumping so many messages into your page? In other words, thousands of messages getting logged to the Console might be a code smell that needs to get addressed

In the spirit of full transparency, our plan right now is to sit on this thread for another week and see the responses. So we're not planning any changes for at least a week. But I want you to know that I'm watching the thread. Hopefully you can now see that we have some conflicting priorities here, and we didn't make this change just to drive you crazy :)

[Viktor Zozuliak]

Still I think that forcing people to something leaving them with no choice is generally not a good idea.

What about giving user the warning when there are errors that are filtered? 

Kinda "Hey, you have errors filtered out - you might want to see them". Where "see them" is link clicking on which errors displaying is being turned on.

понеділок, 5 червня 2017 р. 22:19:23 UTC+2 користувач Kayce Basques написав:

[PhistucK]

On Mon, Jun 5, 2017 at 11:19 PM, 'Kayce Basques' via Google Chrome Developer Tools <google-chrome-...@googlegroups.com> wrote:

In other words, thousands of messages getting logged to the Console might be a code smell that needs to get addressed

​While in the frontend this is uncommon, I can see many log messages in the backend ​(probably because debugging or compile-and-run scenarios are far slower than in the frontend). I would not call this code smell. It is just a way of getting the entire picture whenever you need it, even after the fact, instead of putting breakpoints everywhere. Some teams like that, some teams do not.

Disclaimer - my projects have very few console messages (you can probably count them on two hands). I just did not like the code smell suggestion.

☆PhistucK

[Ken Stanley]

It's important to keep in mind that DevTools has a responsibility towards maintaining the health of the web. Ideally, we want to push the web forward in a faster, more secure, more enjoyable, direction, etc. This goal drives the design of DevTools.

1. Faster: not sure where speed applies to filtering dev tool messages. 

2. Secure: same as #1

3. Enjoyable: so far it looks like no one in this thread is enjoying this change

Shouldn't the goal of the dev tools be to enable developers to be as productive and accurate as possible in their jobs? 

Ideally, when you get an error, the solution is to fix the cause of the error, not just filter it out.

No one here said they never want to see error messages. If anything, they simply want to be able to focus on a specific type of message. 

For example, if I've got one or more JavaScript errors in the console, I may need hunt and peck for where an error is occurring. Why? Because sometimes, especially with frameworks such as Angular, the errors might not be immediately obvious. 

As such, I may need to insert console messages to flag where in the code something is happening. This becomes a very exasperated chore when there are many other types of messages (especially if those messsages fall into the same category as other messages, or higher up the chain). 

If you and your team have never run into this workflow, count yourselves lucky. Not all of us developers can say that. 

This is part of why the DevTools UI switched to the new "severity level" dropdown menu. Being able to filter out errors is kinda like a car manufacture giving you the option to turn off the "engine needs service" messages that you get on your dashboard.

Actually, mechanics (I presume you were comparing us developers to mechanics in your analogy and not the end users) can disable the error codes-very easily. And yes, those error codes will come back. 

The point is, car manufacturers do not impose a specific workflow on mechanics on how to fix a car's problems. They publish a manufacturer-specified set of instructions, but ultimately it's up to the mechanic on whether or not they follow those instructions.

This is also what we meant when talking about getting the DevTools model inline with other logging models. It's not common to be able to filter out errors in other logging models.

People have been asking for examples of other logging models that disallow filtering of messages. In fact, Internet Explorer, Firefox, Safari, and even Opera Dragonfly all offer ways to filter out specific types of messages. If anything, right now Chrome is the only "modern" browser that doesn't. 

This whole topic has kicked off a much broader discussion on the state of logging in general. For example, we've started discussing all of the system messages that other parts of Chrome logs to the DevTools Console. Maybe we need to put pressure on them to stop spamming the Console. Or maybe we need to restructure how these messages get displayed. There's lots of possibilities.

I won't speak for everyone else, but this would be a welcome change. But, I would posit that this is a separate issue from message filtering. 

Personally, I've got to say that I'm impressed with the DevTools' engineers willingness to challenge the status quo in order to think up better solutions.

There is nothing wrong with challenging the status quo. But as you can read in this thread, whether this change is better is certainly a matter of debate (and so far it looks like your users disagree with you). 

This is nothing to do with how talented the dev tools team is, and I hope the decision about message filtering doesn't come down to an ego decision either. You guys have made a great browser that has commanded a very loyal following in the developer community. 

I remember when Firefox (plus Firebug) was the defacto standard for web development. Then along came this really trim, fast, and developer-friendly browser named Chrome. What is Firefox's market share again? ;)

In terms of what to do, I suggest the workflow of adding some unique text to your logs and then using the text box filter to isolate those messages.

Reread what you wrote. Say it out loud to yourself; slowly if necessary. Can you and your team honestly say that's a solution you want to promote for this problem? 

If it is, that is very telling about how you feel about your users: like it or go spit. 

Alternatively, you're asking us to implement a feature that was already in Chrome that you felt was bad enough to remove (filtering by a specific type of message), where instead of the browser doing it, the developers do it. 

But then again, I'm going to have to challenge that person and ask, why do you have thousands of messages getting logged?

Let's not throw stones here. You don't know any of the specifics about this person's situation or their code base. Who are we to judge them for their situation?

Maybe you need to put some pressure on the third-parties that are dumping so many messages into your page?

This is the solution, I won't argue that. However, not all of us work for Google and not all of us have the weight to throw around to third-party library developers.

What do you suggest we do between the variable periods of time between creating issues/pull requests, and having those changes implemented–not to mention any delays due to job-related release schedules for updating internal software (if that's even allowed). 

In the spirit of full transparency, our plan right now is to sit on this thread for another week and see the responses. So we're not planning any changes for at least a week. But I want you to know that I'm watching the thread. Hopefully you can now see that we have some conflicting priorities here, and we didn't make this change just to drive you crazy :)

Call me cynical, but I can't help but walk away from your reply feeling like the decision has already been made, and short of divine intervention/an act of congress, nothing that we (your user base) could say would change your minds. 

I certainly hope I'm wrong. Because that would be a terrible shame. What happened to "do no evil"?

--

"Do not go gentle into that good night. Rage, rage against the dying of the light." — Dylan Thomas

[Zac Spitzer]

Chrome itself is spamming the console with all the various [Violation] messages

[Kayce Basques]

Shouldn't the goal of the dev tools be to enable developers to be as productive and accurate as possible in their jobs? 

Developer productivity is totally another priority for DevTools, of course. I didn't mean to imply that maintaining code health was the *only* priority. It's just that the other priority partly explains the reasoning behind the change.

 

As such, I may need to insert console messages to flag where in the code something is happening. This becomes a very exasperated chore when there are many other types of messages (especially if those messsages fall into the same category as other messages, or higher up the chain). 

Wouldn't the suggestion of adding some unique text to your logs be a more efficient filter here? More efficient than console.log or console.info, which any other script has access to.

This is part of why the DevTools UI switched to the new "severity level" dropdown menu. Being able to filter out errors is kinda like a car manufacture giving you the option to turn off the "engine needs service" messages that you get on your dashboard.

Actually, mechanics (I presume you were comparing us developers to mechanics in your analogy and not the end users) can disable the error codes-very easily. And yes, those error codes will come back. 

Fair enough. Analogies are hard :)

 

The point is, car manufacturers do not impose a specific workflow on mechanics on how to fix a car's problems. They publish a manufacturer-specified set of instructions, but ultimately it's up to the mechanic on whether or not they follow those instructions.

This is also what we meant when talking about getting the DevTools model inline with other logging models. It's not common to be able to filter out errors in other logging models.

People have been asking for examples of other logging models that disallow filtering of messages. In fact, Internet Explorer, Firefox, Safari, and even Opera Dragonfly all offer ways to filter out specific types of messages. If anything, right now Chrome is the only "modern" browser that doesn't.

I think we're talking about logging models outside of the domain of browsers. The fact that all the browsers are doing the same thing might be a sign of groupthink. But I understand your perspective: the fact that all the other browsers are doing it may be proof that it is the best workflow

 

This whole topic has kicked off a much broader discussion on the state of logging in general. For example, we've started discussing all of the system messages that other parts of Chrome logs to the DevTools Console. Maybe we need to put pressure on them to stop spamming the Console. Or maybe we need to restructure how these messages get displayed. There's lots of possibilities.

I won't speak for everyone else, but this would be a welcome change. But, I would posit that this is a separate issue from message filtering.

I think message filtering is part of the broader topic, and solving the broader topic might solve the message filtering problem

Alternatively, you're asking us to implement a feature that was already in Chrome that you felt was bad enough to remove (filtering by a specific type of message), where instead of the browser doing it, the developers do it. 

Ya, this is exactly the challenge that I'm posing.

Going back to the mechanic analogy, you said that mechanics are able to bypass the error codes if they need to. Well, you can still do that with the suggestion that I provided. But DevTools is no longer officially recommending that you use that workflow. So the workflow is still there, but it's not officially endorsed by DevTools (as would be the case if it was embedded in the UI like before).

 

But then again, I'm going to have to challenge that person and ask, why do you have thousands of messages getting logged?

Let's not throw stones here. You don't know any of the specifics about this person's situation or their code base. Who are we to judge them for their situation?

Sorry if I disrespected anyone. Not my intention whatsoever. I'm just a regular dude trying to facilitate debate and find a common ground.

With that said, it's not really a jab at that person. The debate we're having here is the fact that there are third-party scripts, scripts which are out of this person's control, clogging up the Console with thousands of logs. That person wasn't responsible for that.

 

In the spirit of full transparency, our plan right now is to sit on this thread for another week and see the responses. So we're not planning any changes for at least a week. But I want you to know that I'm watching the thread. Hopefully you can now see that we have some conflicting priorities here, and we didn't make this change just to drive you crazy :)

Call me cynical, but I can't help but walk away from your reply feeling like the decision has already been made, and short of divine intervention/an act of congress, nothing that we (your user base) could say would change your minds. 

I really like this community and the fact that people are so engaged in it, and I try my best to represent your interests. Sometimes I have to play the devil's advocate (like now), but I hope you all know it's with utmost respect. The whole point of this forum is to work towards a better solution together

[Kayce Basques]

On Monday, June 5, 2017 at 10:15:05 PM UTC-6, Zac Spitzer wrote:

Chrome itself is spamming the console with all the various [Violation] messages

Right, this is one of the bigger topics that the team started discussing. Like, maybe DevTools needs to rethink how it displays these messages.

But I also think it's possible to filter these out by setting the logging level dropdown to "Info", right?

[Zac Spitzer]

On Tuesday, 6 June 2017 14:48:08 UTC+10, Kayce Basques wrote:

On Monday, June 5, 2017 at 10:15:05 PM UTC-6, Zac Spitzer wrote:

Chrome itself is spamming the console with all the various [Violation] messages

Right, this is one of the bigger topics that the team started discussing. Like, maybe DevTools needs to rethink how it displays these messages. 

 

But I also think it's possible to filter these out by setting the logging level dropdown to "Info", right?

but that's very crude as you then also miss out on seeing your own debug messages.

of course under the old ui, violations could have just been added as their own specific filter option

[Kayce Basques]

On Monday, June 5, 2017 at 10:55:37 PM UTC-6, Zac Spitzer wrote:

On Tuesday, 6 June 2017 14:48:08 UTC+10, Kayce Basques wrote:

On Monday, June 5, 2017 at 10:15:05 PM UTC-6, Zac Spitzer wrote:

Chrome itself is spamming the console with all the various [Violation] messages

Right, this is one of the bigger topics that the team started discussing. Like, maybe DevTools needs to rethink how it displays these messages. 

 

But I also think it's possible to filter these out by setting the logging level dropdown to "Info", right?

but that's very crude as you then also miss out on seeing your own debug messages.

Got it. 

In Chrome 60 there's now a User Messages Only checkbox in the Console Settings menu. That should hide system violations while maintaining your console.debug() calls. Does that work for you?

[Zac Spitzer]

nice, that helps, but the naming is a bit confusing, who is the "user"?

[Dmac]

Hi Kayce,
Thanks for taking the time to reply to us.

I just wanted to echo what Ken has said very elegantly. 

I'm quite sure that the DevTools team is quite talented and experienced. 

I don't think anyone here is debating that.

What I want to emphasize with this post is that there are many developers in situations that are simply out of their control.

There are many developers who are dealing with code from their teammates that are throwing errors, and warnings.
There are many developers who are contractors dealing with someone elses code base.
There are many developers who are dealing with legacy code.
There are many developers who don't have access to other parts of the code that are clogging the logs.
There are many developers who are working in teams of 20 people who are constantly pushing breaking code that throws errors.

On top of all this, other major browsers have ways of filtering info from logs, so if other teammates or contributors are using firefox (for instance) while we want to use chrome, we really are stuck with this.

Besides "corporate speak" as you have said, we haven't actually been given any tangible reasons for why this change has been made.

Let's be honesty with ourselves here. Is there actually any real tangible reasons for this change that benefit the developers (the users of this product. Remember that!)
We haven't actually seen a single one. Not one. 

"Pushing the web forward!" - By removing obviously very popular features and making it objectively more frustrating to read through errors and user logs?
"More things more consistent!" - By fundamentally changing how the logging system works and diverging from every single other browser
"Faster!" - .... 
"More secure!" - ....
"More enjoyable!" - ... Really?


I get that you guys are trying to toe the line with these changes, but I really can't help that the meetings before this feature went out went like this:
"I think the users might get a bit annoyed with this sudden and dramatic change..."
"They don't know what's best for them. We want to push the web forward!™ They'll learn to love it. Just wait and see. They'll be thanking us eventually."


It may seem like a small detail to you guys, but for many of us developers, this is a big deal. 

Why is this a big deal?

Because now every single time I have to look at the console, I have to spend an extra second or two to try and parse all the extra nonsense that is in our console. 
Context adjustment is a real thing. The more time I have to spend parsing the console, even if only for half a second, the more frustrated it makes us, and the more difficult my job is.


I'm asking you again. Please re-consider your changes.

[Ken Stanley]

Developer productivity is totally another priority for DevTools, of course. I didn't mean to imply that maintaining code health was the *only* priority. It's just that the other priority partly explains the reasoning behind the change.

​The problem is, you haven't explained it. You said "It's important to keep in mind that DevTools has a responsibility towards maintaining the health of the web. Ideally, we want to push the web forward in a faster, more secure, more enjoyable, direction, etc. This goal drives the design of DevTools.", which doesn't really tell us anything. In fact, it sounds a lot like marketing speak. How does changing the filtering of console messages make the web faster? or more secure? 

 

Wouldn't the suggestion of adding some unique text to your logs be a more efficient filter here? More efficient than console.log or console.info, which any other script has access to.

​Okay; so what you are suggesting is:

1. Each individual web developer spend their company's time/money to go through all of the existing Javascript code and modify the console messages to add an arbitrary tag, which adds no business value to their product line

2. "Push" third-party library vendors to update their code to add tags to any of their console messages because one web browser decided they no longer wanted to do it like all of the other web browsers, because "status quo"

How is this "more efficient"? Add to the above that the filter box is inclusive only -- in other words, I can only search for what exists, I cannot exclude anything -- and you removed the ability to do regular expression searching. At best, your suggestion is nothing more than a simple band-aid.

 

I think we're talking about logging models outside of the domain of browsers.

What makes the logging models outside of the domain of browsers more powerful / useful than the current model of logging inside of web browsers? 

As an aside, I opened up my Console.app and took a look at how Apple correlates the various message logs on my system. From what I can tell, there are only three distinct classifications: 1) Error, 2) Fault, 3) Message. As such, they have a toggle for those three types of messages. Their search filter allows me to search on things, such as, Date & Time, Process, Process Path... (13 pieces of information in total), and has the ability to do a "Contains", "Does Not Contain", "Equals", and "Does Not Equal". Chrome is nowhere near that savvy with its filter box.

If the decision were mine to make, I would argue that other models should inherit from the browser model, and not the other way around. 

 

The fact that all the browsers are doing the same thing might be a sign of groupthink.

Ah, so it's merely a matter of being different. Noble, but in this case, misplaced.​

Going back to the car analogy, have you ever considered why cars and trucks follow the same fundamental designs (e.g., round wheels, rubber tires, steering wheels, dashboards with the same icons)? Because 1) they work, and they work really well, and b) people are intimate/comfortable with how they work. ​Take a moment to imagine what would happen if a car manufacturer arbitrarily decided to switch the locations of the gas and brake pedals. What if turning the steering wheel to the right actually turned the car to the left (and vice versa). Even cars with paddle shifters still allow the driver to use the car without having to use the paddle shifters. 

Creativity and innovation are great things, but not at the expense of usability. Also note that groupthink works in both directions (i.e., discourages individual responsibility: i.e., have the developers tag their messages so Chrome doesn't have to manage it). 

 

Ya, this is exactly the challenge that I'm posing.

Going back to the mechanic analogy, you said that mechanics are able to bypass the error codes if they need to. Well, you can still do that with the suggestion that I provided. But DevTools is no longer officially recommending that you use that workflow. So the workflow is still there, but it's not officially endorsed by DevTools (as would be the case if it was embedded in the UI like before).

​If my radiator hose develops a leak, I know I can use duct tape over the hole long enough to get me to a repair shop. The same thing for using a donut tire when I have a flat. Those are both temporary solutions, and do nothing to solve the larger problems.​

​Alternatively, I could write a Chrome plugin that would extend the console methods and add a tag automatically to any message; i.e., monkey patch. But what happens when new types of messages are added? ​What about when they are removed? This still does nothing to address the ability to toggle between the various states of messages in the console. 

[PhistucK]

On Tue, Jun 6, 2017 at 9:23 PM, Ken Stanley <doh...@gmail.com> wrote:

How is this "more efficient"? Add to the above that the filter box is inclusive only -- in other words, I can only search for what exists, I cannot exclude anything -- and you removed the ability to do regular expression searching. At best, your suggestion is nothing more than a simple band-aid.

​Both of those arguments are not true.

1. You can begin the filter string with a minus operator to exclude. Example, enter -

-failed

In the filter and anything that has "failed" in it will go away.

2. In order to use regular expressions, start your filter with a slash -

/failed.+to/

(I guess this can also be used to exclude things, with some regular expression trickery)

☆PhistucK

[Ken Stanley]

​Both of those arguments are not true.

1. You can begin the filter string with a minus operator to exclude. Example, enter -

-failed

In the filter and anything that has "failed" in it will go away.

​This does not work in  58.0.3029.110 (Mac). 

 

2. In order to use regular expressions, start your filter with a slash -

/failed.+to/

(I guess this can also be used to exclude things, with some regular expression trickery)

​Sweet. I didn't think to use the slashes. Thank you! ​

[PhistucK]

Oops. You are correct. The minus thing does not work. I was imagining. :)

☆PhistucK

--
You received this message because you are subscribed to the Google Groups "Google Chrome Developer Tools" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-chrome-developer-tools+unsub...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-chrome-developer-tools/CAN%3DNbA%2B1QmftTfsyxxNJzWUsmGSfozkcKMW0DVZs0qr9PKOv%3Dw%40mail.gmail.com.

[Kayce Basques]

Here's the gist of the disagreement, as I understand it. Again, I'm not speaking officially on behalf of the team anymore.

• My argument (new UI argument)
• The change happened because DevTools wants to move to a model where console.error() is treated as a failure that you can't (easily) ignore. This is why the ability to only show one type of console message, such as console.info(), was removed. Because it let you ignore errors. This implicitly puts pressure on developers to fix the source of the console.error() messages if they don't want to see them in their Consoles anymore.
• An analogy: suppose DevTools had a checkbox that let you ignore uncaught exceptions. But then they removed that checkbox, to put pressure on developers to fix those uncaught exceptions.
• In other words, DevTools wants to move to a mental model where console.error() is treated more like uncaught exceptions.
  
• Your argument (old UI argument)
• This change is reducing my productivity. Developer productivity should be the number one priority for DevTools.

Philosophically, I think there's two conflicting viewpoints here about the purpose of DevTools:

• New UI argument: By design, DevTools should steer developers in a direction that improves the quality of sites.
• Old UI argument: DevTools should be an open-ended toolbox that gives me complete control over a page. So, using the two examples from above, maybe DevTools should let me ignore uncaught exceptions, or ignore console.error() messages, if that's what I need to do.

I'm personally on the fence about where I stand regarding these two viewpoints. I'm leaning towards a "let's do both" solution, where the default DevTools UI tries to steer you in a direction, but there's advanced / hidden settings that let you do things that DevTools deems "dangerous".

[Dmac]

I ran into a perfect example this morning of why this mentality completely breaks down:

Working on a feature branch in git, a coworker pushed some code that was breaking the code I was testing, and was filling my entire console with errors.
Now, I understand what you guys are trying to do now, but it completely destroys the debugging experience in scenarios like this. 

In situations where you are dealing with someone else's code that they are debugging, legacy code , etc.. then this mentality is not helpful.

In fact, many of us are actively trying to fix our errors, but the console could be spitting out a ton of errors and we need to hide them.

[Heath Bishop]

If I completely controlled all of the code I work on then I would be all for "new UI argument".  But unfortunately that is not the case.  I have to work with third party libraries and  code from other teams.  All people I have little to no contact with.

I am all for code quality improvements and standards. This industry definitely needs it. I just don't think this is the best way to go about it.

[Dante Federici]

I'd like to chime in again on this UI issue.

I understand the motivation for console violations. I understand verbose errors being a way to push developers to address problems as opposed to ignore them.

I can deal with errors in the console -- what I don't understand is the move away from an existing, useful de-facto API:

https://developer.mozilla.org/en-US/docs/Web/API/Console

I understand that Chrome doesn't need to adhear to the MDN or anything like that, but I'd like to point out clearly:

The most frequently-used feature of the console is logging of text and other data. There are four categories of output you can generate, using the console.log(), console.info(), console.warn(), and console.error() methods. Each of these results in output that's styled differently in the log, and you can use the filtering controls provided by your browser to only view the kinds of output that interest you.

Regardless of what the Chromium team thinks is the right direction to go, there is a very clear understanding of interaction with specifically the console.* functions. I don't care about productivity, making opinionated tools to push developers to "write better code" (read: not your job to do.), or any of that.

What I care about is the contract that browsers (and as such the tools they provide) have with developers. That is a tool to display, run, and develop web technologies. I don't see this logging change as "OH MAN THE WORLD IS BURNING". I see it much more a decision that someone thought was a good idea, and made a good case for, but didn't really consider the workflows people had set around a system that was already in place.

In fact, I'd MUCH rather the dev team there fix the long outstanding issue of filtering console.group messages. (an issue since 2014!) see this chromium issue report for a discussion on this issue

What I want to see is improvements to help developers. Not improvements focused on what the team thinks developers need.

[Ken Stanley]

I'm personally on the fence about where I stand regarding these two viewpoints. I'm leaning towards a "let's do both" solution, where the default DevTools UI tries to steer you in a direction, but there's advanced / hidden settings that let you do things that DevTools deems "dangerous".

​Alternatively, if you were going to do a "let's do both" solution, you could leave the Levels dropdown as-is*, and include the old level toggles**​. Then, if the user switches the Level dropdown, the toggles would update to reflect the level they selected. If the user cherry-picks a set of levels using the toggles, the Levels dropdown could switch to a "Custom"* choice that lives only as long as the toggle selections exist (I hope that made sense). You and your team get to have your consolidated logging model, while us "old-schoolers" can still have the flexibility of toggling our console messages. 

​** If the team decides to keep the toggles (please please please), would you add a switch for "Violations"? :)

Thank you!​

[Kayce Basques]

Check out Canary ;)

https://codereview.chromium.org/2920183003

[maarten....@sorama.eu]

I want my error filter back :(

[David McGregor]

Kayce, I think this is a really really good decision that the devs have made, but this now begs the question:

If we now have the ability to filter out errors, then what reasoning is there to limit the "info" filter to simply one channel?

I'm personally of the opinion that splitting the .log() and .info() was a great feature, and with service workers becoming more ubiquitous, it would be nice to have some extra way to discern. I really like the idea someone had suggested above of allowing us to create our own 'custom channels' much like the custom device menu works.

Either way, thank you sincerely Chrome Devs and Kayce for listening to your users.
This change is at least enough to get us to stop whining. :)

Cheers

--

You received this message because you are subscribed to the Google Groups "Google Chrome Developer Tools" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-chrome-developer-tools+unsub...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-chrome-developer-tools/cc79cdd5-f26b-4d32-9f05-45618c234032%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

David McGregor

1-844-515-1992

Software Developer

The Better Software Company

 

[Heath Bishop]

This is definitely a step in the right direction.  Though far from complete.  What version of Canary are you using in the picture?  I don't see that ability with 61.0.3122.0.

[Kayce Basques]

If we now have the ability to filter out errors, then what reasoning is there to limit the "info" filter to simply one channel? 

I'm personally of the opinion that splitting the .log() and .info() was a great feature,

I think the reasoning is that they are semantically redundant. In other words, why have two functions that signify the same type of informational-level message?

 

and with service workers becoming more ubiquitous, it would be nice to have some extra way to discern. 

I think this service workers is an example where we need to rethink how stuff gets logged to the Console. I think we can think up a better solution than relying on semantically-redundant functions.

P.S. I'm pretty sure that you can already use the context selection menu to only show service worker messages only.

I really like the idea someone had suggested above of allowing us to create our own 'custom channels' much like the custom device menu works. 

Either way, thank you sincerely Chrome Devs and Kayce for listening to your users.

I didn't really do anything other than facilitate discussion on here, so they must have been monitoring the thread. I really do mean it when I say that the team cares about their users and pays attention to your feedback.

[Kayce Basques]

This is definitely a step in the right direction. Though far from complete.  

What else are you looking for?

I personally find it less-than-optimal that I need to open the menu multiple times to select my levels. E.g. open the menu, select an item, the menu closes, then I need to open it again to select another item.

 

What version of Canary are you using in the picture?  I don't see that ability with 61.0.3122.0.

"61.0.3124.0 (Official Build) canary (64-bit)" on Mac

[Viktor Zozuliak]

This is amazing! 

One question here: what `info` means? Is this `log` + `info`? Will there be any way to distinguish between `log` and `info`?

четвер, 8 червня 2017 р. 16:03:02 UTC+2 користувач Kayce Basques написав:

[Kayce Basques]

On Thursday, June 8, 2017 at 10:28:11 AM UTC-6, Viktor Zozuliak wrote:

This is amazing! 

One question here: what `info` means? Is this `log` + `info`? Will there be any way to distinguish between `log` and `info`?

Yes, console.log() and console.info() both fall under that bucket. I think the reasoning for grouping them together was that, semantically, they both represent informational messages (as opposed to warnings, or errors).

Although I just looked at the Console Spec and it's defining console.log() as a "generic" message. Almost like the severity levels don't apply to it. So maybe the severity level of console.log() is debatable.

[Heath Bishop]

What else are you looking for?

I personally find it less-than-optimal that I need to open the menu multiple times to select my levels. E.g. open the menu, select an item, the menu closes, then I need to open it again to select another item.

 

I completely agree.  I was simply pointing to the fact that we now have an option to select multiple items, which is a step in the right direction.  Honestly, I want a more advanced version of what Chrome previously had.  Where the mentality is "The more developer options, the better".  We are not end-user idiots that need things dumb down for us.  We are developers and engineers.  Our hands are deep in the code everyday.  And not just web technologies.  Many of us also use JAVA, .Net, Swift, etc.  In other words, we are not script kiddies.  While I'm being honest, the conversations here have really shown just how OUT OF TOUCH the dev-tools team really is.  Chrome is nothing more than a tool that helps us do our jobs.  Granted it's a tool that many of us use, but it's not our only tool.  The new dev-tools limitations and how out of touch the dev-tools team is, is the reason my entire team has completely switched all development to Firefox Developer Edition.  We now just use Chrome to check for compatibility.  It was just the other day that I overheard a coworker tell another coworker "it's a Chrome issue, switch to Firefox".  If loosing your development community is your goal, then your on the right track.

 

What version of Canary are you using in the picture?  I don't see that ability with 61.0.3122.0.

"61.0.3124.0 (Official Build) canary (64-bit)" on Mac

That explains it.  I'm on Windows. 

[Lindsay Stillwell]

I've seen many third party libraries leave in console.info and console.warn messages that are shown in the console while developing. I would like to be able to single out "console.log" so I can see only the messages that I personally wrote. With the previous UI my most commonly used filter combo was Log + Error.

[Bergsicht]

I would like to ask if you can add trace and debug as selectable level?

[Frederico Guth]

I just joined the group to be another angry developer complaining about changing something that wasn't broke.  

It has been mode than a month... is there a solution?  How can we go back to the old way?

[PhistucK]

It was recently fixed. Unless something gets reverted, the fix will show up in Chrome 61 -

https://github.com/ChromeDevTools/devtools-frontend/commit/9a6d4e25634654e49ca40d0c3094a81ce2c48fe1

I asked them to merge it to Chrome 60 (and 59, but do not count on it) -

https://codereview.chromium.org/2920183003/#msg11

No need to add another comment there, just ask for a merge here if you were going to add a comment to that effect there.

☆PhistucK

--

You received this message because you are subscribed to the Google Groups "Google Chrome Developer Tools" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-chrome-developer-tools+unsub...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-chrome-developer-tools/1b8a6f47-6385-43db-9fab-1f1aa6846e58%40googlegroups.com.

[Ken Stanley]

It was recently fixed. Unless something gets reverted, the fix will show up in Chrome 61 -

https://github.com/ChromeDevTools/devtools-frontend/commit/9a6d4e25634654e49ca40d0c3094a81ce2c48fe1

I asked them to merge it to Chrome 60 (and 59, but do not count on it) -

https://codereview.chromium.org/2920183003/#msg11

No need to add another comment there, just ask for a merge here if you were going to add a comment to that effect there.

Hoorah! Thank you for making this cynical old man happy! :)

One last question: ​it may have gotten lost in the thread, and I didn't see anything in the bug tracker, but will we at some point be able to exclude 'Violation' messages from the console?

[Kayce Basques]

One last question: ​it may have gotten lost in the thread, and I didn't see anything in the bug tracker, but will we at some point be able to exclude 'Violation' messages from the console?

See https://groups.google.com/d/msg/google-chrome-developer-tools/kH3FiDLlsFg/9pUY54eXAAAJ 

[Bergsicht]

I would like to repeat that it would be nice to add two levels:

var levels = [
- {value: ConsoleModel.ConsoleMessage.MessageLevel.Verbose, label: Common.UIString('Verbose')},
- {value: ConsoleModel.ConsoleMessage.MessageLevel.Trace, label: Common.UIString('Trace'),},
- {value: ConsoleModel.ConsoleMessage.MessageLevel.Debug, label: Common.UIString('Debug'),},
- {value: ConsoleModel.ConsoleMessage.MessageLevel.Info, label: Common.UIString('Info'), default: true},
- {value: ConsoleModel.ConsoleMessage.MessageLevel.Warning, label: Common.UIString('Warnings')},
- {value: ConsoleModel.ConsoleMessage.MessageLevel.Error, label: Common.UIString('Errors')}
- ];


Thank you very much in advance!

[Zac Spitzer]

Is there a way with the new UI to just quickly filter to only error messages? 

the only way at the moment I can see is to manually uncheck all the other levels

[Heath Bishop]

The update in Canary is better, but what about Logs?  Grouping info and logs together is a terrible idea.

[Kayce Basques]

The update in Canary is better, but what about Logs?  Grouping info and logs together is a terrible idea.

I think the reasoning for grouping them together is that they both represent "informational" level messages.

[Kayce Basques]

On Monday, June 26, 2017 at 12:33:16 AM UTC-7, Zac Spitzer wrote:

Is there a way with the new UI to just quickly filter to only error messages? 

the only way at the moment I can see is to manually uncheck all the other levels

I filed a request to make this workflow more user-friendly: https://crbug.com/737198