Learn what's new in the Chrome Developer Tools.
If you missed this at Google I/O, check out the great #io12  session by +Sam Dutton and  +Pavel Feldman that shows you what's new in the developer tools, including some hidden gems.
http://goo.gl/yIshT
126
128
Yuriy Portnykh's profile photoYusuke Kaji's profile photoManuel Alzurutt's profile photoXi Cheng's profile photo
11 comments
 
Always great to see improvements in Chrome!
 
Sold. Tomorrow I'm switching from Firefox to using Chrome as my dev tool.
 
What's with the minified link? This isn't twitter here.
 
goo.gl also provides stats 'n stuff, so maybe they're monitoring... something.
 
I am still using Firebug as dev tool - if Chrome don't start to show full ajax request info in console I suppose I will not use it as main dev tool at all (It is very annoying because Chrome is  the best browser but it is lacking such an important feature)
 
Hi Todor – what information would you like to see in the console?

Take a look at Chrome Canary for an idea of what's already been implemented: Canary displays the URL of the file retrieved, which links to detailed information in the Network panel. In the console, you also get a link to the function that makes the Ajax request. You can also add XHR breakpoints: go to XHR Breakpoints from the Scripts panel (Sources panel in Canary).

If none of that is what you want, let us know – or file a bug at new.crbug.com.
 
Hi Sam and thanks for the comment.
Yes I know that Chrome dev tool has all the things (and even more) that Firefox has but in Chrome they are not so "close at hand". For example - I have to debug several ajax requests (more than one time) - in Firebug I have all the information about them in my console and I don't have to go anywhere else. In Chrome:
1. First I have to enable XMLHttpRequests (which should be enabled by default - correct me if I am wrong but I don't know a web site in our time which is not using ajax).
2. When I click the dropdown arrow I see information that I do not understand and is not useful for me.
3. When I click the link I am redirected to the network panel where I see a lot of requests and I am lost and not knowing which one to choose.
4. When I finally find it and click it the panel changes (which is also unpleasant because I have to go several panels back to where I was) and I see some unformatted information which costs me additional energy and frustration to read.

Every of these steps are unpleasant and unnatural to me - I just want to stay in the console where I can execute JavaScript and to see the fully formatted information about all the ajax requests.
I know that Google is working really hard on Chrome and you are doing great by pushing Html5 forward but the natural and easy way of working with the new technologies is also important. I don't know about you but I just cannot stand to debug for example 10 ajax requests following the above steps.
I am writing this hoping that things will change for good. I also hope that some of your colleagues from the Chrome team will hear this.
(I will also post this as a new issue on the Chromium site's link that you gave me).

Best regards,
Todor Pavlov 
 
Thank you for your feedback! And yes, you should definitely file a bug at crbug.com/new where we would be able to discuss issue in greater detail!

I think I now understand your workflow. You are testing your backend using the DevTools and you are issuing commands in the console that fire XHRs against your server. When you type a command, you expect to see XHR entry in the console as a feedback to your action. Is that right? I think we don't do particularly good with this scenario. Let me try to explain why we have it this way. 

> 1. First I have to enable XMLHttpRequests (which should be enabled by default - correct me if I am wrong but I don't know a web site in our time which is not using ajax).

We think of console as of Terminal. We hate it when there is one of the apps running in the background that is logging into stdout extensively as we type other commands. In the old days, XHR was a rare thing and showing it in the console by default meant nothing bad for the developer. Today, console quickly gets flooded with the XHRs. Just open Gmail with this option enabled and see how quickly console becomes useless. People dealing with DOM / JavaScript do not necessarily appreciate random XHRs popping up there.

> 2. When I click the dropdown arrow I see information that I do not understand and is not useful for me.

This is done for consistency with other console.* commands that dump caller stack. Knowing what JavaScript stack requested XHR is sometimes useful. We have tons of instrumentation in the browser and would not want to differentiate XHRs much. It already special and it has its menu item in the context menu. We think of logging XHRs into the console as of "monitorEvents" command from the command line API.

> 3. When I click the link I am redirected to the network panel where I see a lot of requests and I am lost and not knowing which one to choose.

This sounds bad. We should open that particular XHR for you. Please file a bug.

> 4. When I finally find it and click it the panel changes (which is also unpleasant because I have to go several panels back to where I was) and I see some unformatted information which costs me additional energy and frustration to read. 

As I mentioned above, we don't seem to handle "XHR debugging using console" scenario well. Please get back to us with the issue filed and we'll make sure it gets fixed.

Regards
Pavel
 
Hi Pavel,
Thank you that you took the time to explain me your point of view for this problem. I understand you but still there should be an easy way to test XHR.
I posted a bug on crbug.com and I will post a separate one about that clicking a XHR link leads to the Network panel and not to the XHR itself.
Regards,
Todor
Add a comment...