~robcee/ more than just sandwiches

Firebug Features Poll part 2 – The Unloved

This is the second part of the Firebug Features Poll (part 1 is here). This time, focusing on the answers to the question: What is your least favorite Firebug feature. The one you never use. I don’t know if the question was worded poorly or if people just felt like venting, but many of the responders didn’t limit themselves to just one thing. As a result, I had to modify my non-scientific methodology a little bit and count mentioned features as votes instead of just lumping the responses into a single feature bucket.

As in the previous poll, I added a Junk column for responses that didn’t really make sense. “I <3 Firebug!” is great to hear (and Firebug <3s you too!) but it wasn’t really useful for the purposes of this poll. Augmenting this column, I created another category for responses lamenting Firebug stability or specific missing features. This was tied for first place with the most votes.

The Winners

Third place – Tie!

• Search feature
• Console. Surprised some people dislike the Console, but two of you did. One person mentioned a lot of exceptions coming from the browser showing up in the Console lowering the quality of information. These can often be cut down by unchecking the “Show Chrome Errors” and messages options in the Console’s mini-menu.

Second place – Tie!

These have the dubious distinction of having the same number of responses as the Junk column.

• CSS panel
• DOM panel
• Profiler

First Place

• Script panel — Responses varied from “I don’t know how to use breakpoints” to users who prefer using the Console to do printf-style interactive debugging. Other respondents claimed the script panel was just too buggy.

caveat: I believe there is probably more than one type of user of Firebug. Some of them may not be using Twitter and this poll might not have gotten to them. The types of users who replied and said that their favorite feature was the HTML Inspector and live-editing of CSS are probably the same group of people who don’t make heavy use of the Script debugger. If you’re a heavy debugger, please let us know in the comments.

Honorable Mentions

• HTML node editor – If you double click on a tag in the HTML view, you’ll see the node editor. Clicking the “Edit” button or using the Escape key will get you out of it.
• Event logging – right click on a node in the HTML viewer and select “Log Events”. Now every mousemove, click and keystroke in that node will be registered in the Console. How can you not love that?

There were no votes(!) for the Net panel, so everyone clearly loves it and thinks it’s awesome.

Take Aways

• we need to work harder on bugfixes and stability. Spending a lot of effort on stability and usability would probably go a long way towards making Firebug a better, more pleasurable to use piece of software.

• The CSS and DOM tabs aren’t loved. Adding better navigation to the DOM page, or reworking it entirely might be useful. Getting rid of it and the CSS tab entirely could be another option but not one we’d consider doing without some very strong feedback from the community.

• The Profiler ties in with the Script panel pretty closely. If you’re not doing heavy JS debugging, you might not need the profiler. It’s a pretty special-purpose tool to measure a page’s JavaScript performance.

• Search feature was a bit of a surprise, but we’re improving that for version 1.5 so hopefully it becomes easier to use.

As before, please leave us your comments if you think we’re missing something.

Yes, we make heavy use of the script debugger! Stability and bugfixes for the script panel is our #1 desire.

The functionality of the CSS/DOM tabs is needed. Whether the current Firebug UI for it is good is a separate question.

I personally never use the CSS and the DOM panel and have very strong problem using the script panel. A rework of those would be very cool.

I’ve only used the script tab scarcely, relying on the console tab for testing and debugging. I can’t give a reasonable answer as to why I haven’t used the script tab, but after reading about the features it holds, I’ll throw the script tab at whatever bugs and quirks I might encounter in the future.

I agree with Daniel Nautre, DOM and CSS is mildly useless. Not because they don’t have their uses, but because the integration with the inspection tool is much better than with a seperate tab for each of them.

For what i’ts worth, I found this throught the mozilla planet RSS.

Don’t worry, James. I know there are more of you out there. Thanks for the note.

I use the script debugger and the DOM panel. The CSS panel is only used when I’m checking to make sure a style is being parsed.

Were there any suggestions on how the specific features could be improved or what about the features was annoying/needed work?

I work for a company developing a complex remote-XUL app and would love to use the script panel, but it fails to work at all for us. One of my colleagues has it as his #1 complaint about our dev environment. I get by with console logging, but being able to use breakpoints – or at least the “debugger” keyword – would make life a lot easier.

As mentioned above, DOM and CSS are great as part of the inspector, less so as distinct tabs.

BTW if anyone’s looking for a new job and fancies a remote-XUL developer position, we’re actively hiring at the moment: http://www.peppertop.com/blog/?p=607

kevin: Rypple encourages short responses so there wasn’t a lot of room there for in depth analysis and suggestion. As Daniel, Mads and Trevan suggest, several people opined that the CSS panel was “useless”. Using it as a validation tool seems to be one of the only uses for it, so maybe reworking it to do that job better would be an improvement.

MarkC: I wish I could help you, but Firebug isn’t really designed to work on XUL apps. Chromebug is probably what you’re looking for, but it could use a little extra love.

You can find a link to it here: http://getfirebug.com/extensions/index.html#chromebug

Thanks for the comments!

Unfortunately there don’t really seem to be any tools that work reliably with _remote_ XUL. Venkman won’t debug our app. Firebug won’t debug our app. Chromebug crashed my browser when I tried it a few days ago, to the extent that I had to manually remove the Chromebug files from disk before I could even get Firefox to launch.

Firebug actually used to do a better job of debugging our app than it does now – but I don’t know how much the change is down to newer Firefox/Firebug releases, and how much is down to changes in our code. The “debugger” keyword used to work, and the script debugger was very close to working other than getting line counts out of whack resulting in breakpoints occurring at different locations in the code to where they appeared in the script tab. Now none of the script stuff works at all.

The bits that do work mean that Firebug is still a great tool for us, but I do appreciate that it’s first and foremost a tool for HTML development (which is why I haven’t bothered filing bugs about debugging remote-XUL).

I’m a fan of the DOM panel. Very useful to me when I was learning how ExtJS worked. It was nice to be able to follow the tree down and learn about the structure of things.

The console is invaluable in debugging scripts to me and my coworkers, so don’t listen to the guys who knock it.

I love the “Call Stack” tab and “Break on All Errors” option. Debugging in Firebug has gotten better!

I don’t use the script debugger often, but when I need to, it saves a tremendous amount of time versus sprinkling log statements throughout my code and guessing where things may be broken.

The stability of the debugger and breakpoint accuracy was substantially improved from whatever earlier version I was using to Firebug 1.4.3 today. Sincerely, awesome work on improving the debugger!

[...] siguiente es una traducción de un post de Rob Campbell (Aquí está el original), uno de los desarrolladores de [...]

“Using [the CSS panel] as a validation tool seems to be one of the only uses for it, so maybe reworking it to do that job better would be an improvement.”

So maybe it could be replaced by a “Validation” panel that includes HTML validation and JS linting?

“[Console noise] can often be cut down by unchecking the “Show Chrome Errors” and messages options in the Console’s mini-menu.”

The default probably shouldn’t include chrome errors. Maybe it should be a tab/toggle between chrome and content, rather than a toggle between “include chrome errors” and “don’t include chrome errors”.

Jesse, people do use the CSS panel as a few commenters here mentioned. I wouldn’t mind having a validation extension for Firebug though.

Definitely agree chrome errors should probably be shut off by default. I’ll check into that.

Thanks for the comments!

I literally would not be able to do my job if it were not for the CSS panel in Firebug.