If you select Log, you see errors. The drop down configures the verbosity filter like in pretty much all loggng systems...
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.
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 view this discussion on the web visit https://groups.google.com/d/msgid/google-chrome-developer-tools/CAEX3KhYhajkY2rZ9997r_wubr0KhwkTQoCqSWJ4etY%3D_pX5pZA%40mail.gmail.com.To unsubscribe from this group and stop receiving emails from it, send an email to google-chrome-developer-tools+unsub...@googlegroups.com.
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.
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?
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.
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.
Having to hold shift to select multiple filters was a bit obscure
a checkbox approach is more intuitive to first-time users
The drop down configures the verbosity filter like in pretty much all logging systems
--
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.
I use `debug` for the explicit purpose of easy filtering, and I generally remove all debug statements once the code is working and tested.
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.
Sidebar:While I'm here, it is VERY obnoxious that the filter string doesn't filter on the label for grouped console messages.
--
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.
+1
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
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.
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.
--
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.
In other words, thousands of messages getting logged to the Console might be a code smell that needs to get addressed
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.
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.
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 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 :)
Shouldn't the goal of the dev tools be to enable developers to be as productive and accurate as possible in their jobs?
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).
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.
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?
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.
Chrome itself is spamming the console with all the various [Violation] messages
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] messagesRight, 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?
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] messagesRight, 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.
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.
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.
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.
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).
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 --failedIn 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)
--
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.
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()
, andconsole.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.
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".
--
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.
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 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.
This is amazing!One question here: what `info` means? Is this `log` + `info`? Will there be any way to distinguish between `log` and `info`?
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
--
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.
It was recently fixed. Unless something gets reverted, the fix will show up in Chrome 61 -I asked them to merge it to Chrome 60 (and 59, but do not count on it) -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.
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?
The update in Canary is better, but what about Logs? Grouping info and logs together is a terrible idea.
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