[masklinn]

> but firebug blows chrome's debugger out of the water.

Could you please describes the ways in which it "blows chrome's debugger" [actually the Webkit Development Tools, it's been much more than a debugger for quite a long time) "out of the water" in your opinion?

[ptarjan]

One wonderful thing about Firebug:

When editing a CSS property, pressing UP and DOWN will iterate through all of the possible values of that property. For example, editing "display: none", you can quickly find out what values "display: " can take.

I really miss that in the chrome debugger :(

[masklinn]

True, the webkit DOM inspector can only increase or decrease numerical value, it doesn't work for arbitrary values (I actually find worse that it does not autocomplete property values)

[nowarninglabel]

Yeah, I'd also like to see an analysis of this. I used to be an automatic 'switch to Firefox for debugging' user, but I find that the Chrome developer tools are now pretty sufficient.

[etherealG]

a small example, not really analysis, but it does count. one of the reasons I still use ff instead of chrome for debugging is that on post requests viewing the raw source of a page requires chrome to repost to the server. ff just shows me the page/data as it came back without the repost, which can be critical in debugging stateful posts where a double post effects state.

[masklinn]

I'll have to test that, that doesn't seem to happen in the resource viewer of Safari 5.

[jlangenauer]

Here's one example: I've found that in certain cases Chrome's debugger sometimes can't link back to the line number where an error is caused when that line is inside an anonymous function, whereas Firebug often can.

That said, I do most of my debugging in Chrome, only switching to Firefox/Firebug when they fail me, which isn't too often.

[adhipg]

One thing that I always go back to Firebug is for the 'Persist' mode on the Network tab. In case your server side code is redirecting to some other page or site (payments etc) you need to see what was passed to the server and what redirection loops is it going through etc.

Another thing that I haven't found Chrome to be able to do is show me events in the DOM tree (I admit I need FireQuery to do that). That really helps you figure out what events are associated with a particular DOM element.

[masklinn]

> Another thing that I haven't found Chrome to be able to do is show me events in the DOM tree (I admit I need FireQuery to do that). That really helps you figure out what events are associated with a particular DOM element.

Safari's version has that, not sure about Chrome.

In the DOM inspector, right pane (the one starting with the Styles group), scroll to the bottom and you might find a group called "Event Listener".

You can even switch between viewing only the events bound specifically on the currently-selected node, or those bound on all its ancestors as well (to visualize the bubbling sequence).

[csomar]

There is no equivalent to the Firefox JavaScript console, especially when you add the jQuery plugin to it. Chrome console sucks. Their DOM explorer is superior in some ways, though.

[masklinn]

> There is no equivalent to the Firefox JavaScript console [...] Chrome console sucks.

So there is indeed an equivalent, which you don't like for reasons you refuse to explain. I am disappoint.

[mootothemax]

So there is indeed an equivalent, which you don't like for reasons you refuse to explain. I am disappoint.

Agreed, I'm genuinely interested to know what I'm missing out on! :)