- Published:May 22nd, 2009
- Comments:34 Comments
- Category:Firebug, Planet Mozilla
See also post related to Firebug 1.5 activation.
A while ago, I have written a post about Firebug 1.2 activation that is used to enable and disable certain Firebug features and avoid performance penalties the user could pay when not using Firebug and just browsing with Firefox.
Since that time we have gathered a lot of feedback related to the activation model saying in short: it's too complicated, I don't understand how to use it. Even if it's not exciting to receive negative responses, thanks to all who took the time to explain what could be done better!
We worked hard to improve the activation. Kudos to John J. Barton who put a good deal of work into this and also thanks to Steve Souders for all his input.
So, read the rest of the post if you interested in how the activation model has been designed for Firebug 1.4.
Overview
The overall user experience for activation has three parts: deciding which panels to have enabled (see Firebug Panel Enablement), opening Firebug on pages you want to debug (see Page Activation), and finally deciding where you want to see Firebug (see Firebug UI Placement). Most users will select panels once. After that, the common operations will be:
- One click to open Firebug on a web page, Ctrl+R to reload the page to see details in the Console, Script or Net panel.
- One click to minimize Firebug, work with the page, one click to reopen Firebug.
- One click to close Firebug on a page you don't want to debug after all.
Don't let the details below obscure the basic simplicity of the mechanism. There are no blacklists, whitelists, or regular expression filters involved.
One important message: the meaning of the firebug icon has not changed. If the icon is orange, Firebug is actively analyzing the web page; if the icon is gray, Firebug has minimal overhead.
Firebug Panel Enablement
A global action, not site specific. This mechanism allows disabling panels that are not useful for particular user. This is applied on Console, Script and Net panel (all disabled by default).
UI Commands:
- Enable/Disable (panel mini-popup-menu) enables/disables individual panel.
- Enable/Disable All Panels (status-bar context-menu) enables/disables all panels at once.
Enabling panels causes extra debugging overhead on Web pages active for Firebug.
Page Activation
Opening Firebug UI activates the selected Firefox tab - this means Firebug is now analyzing the Web page. Navigating from an active page to any page in the same domain also activates that new page.
Navigating to a page outside the domain of an active page or changing Firefox tabs to an inactive page (eg gmail), causes Firebug to suspend (no extra debugging overhead).
Closing Firebug with the 
button makes the page inactive for Firebug - this means Firebug is suspended with minimal overhead.
Firebug remembers active pages and closed pages. When the page starts to load, Firebug opens if the page was active last time. If a page was closed last time, Firebug will not open (even if the load was caused by a link from an active page).
Activating a page does not fill the Console, Script, and Net panels with complete information. Users must reload the page to get correct information.
UI Commands:
- Toggle Firebug (status bar icon left click) - Toggles between Open and Minimized (see below).
- On for all web pages (status-bar context-menu) – Firebug UI is opened automatically for all pages.
- Off for all web pages (status-bar context-menu) – Firebug UI is closed (or not opened) for any loaded page.
Firebug's context menu (status bar icon right click).
Firebug UI Placement
Firebug UI can be in one of four places:
- Closed
- Opened in-browser
- Opened in-new-window (aka detached)
- Minimized
In all cases there is always one Firebug window per Firefox window. Its content is automatically updated according to the selected Firefox tab.
UI Commands:
- Minimize Button
(Firebug tab-bar) – Minimizes Firebug UI while keeping all enabled panels running - the status bar is icon still orange. When the Firebug UI is restored, the panel contents will be refreshed as if the UI had been up all the time. - Open Firebug In New Window
(Firebug tab-bar) – Opens Firebug in a new separate window (detach). - Close Button (Firebug tab-bar) - Closes Firebug and all enabled panels are suspended - now the status bar icon is gray.
34 Comments
[...] How to enable and disable Firebug 1.4 [...]
[...] New Activation Mechanism [...]
This simply makes no sense. Having the Firebug UI open is orthogonal to having it running. Suppose something weird happens as a result of AJAX while I had Firebug closed to get it out of the way (or because I didn't remember to open it ahead of time). Before, since I had Firebug set to be active always for my site, the request would have been captured and I'd get to look over it. Same for any other console activity. Now I have to keep it open, and open it manually *each time*, or have to try and reproduce the situation (which may be impossible)?
In short: Keep baby, throw out bathwater.
Agreed, this is crazy! It was sooo much better before - I don't understand why you'd change it. The site level activation was perfect.
I agree also, this change is terrible! 🙁
Now I need to resort to proxies to record requests/responses. Firebug was the best method as it previously could be enabled by domain and didn't interfere w/ your connection.
Firebug 1.4 is one of the most epic fails I've ever witnessed.
This change makes sense conceptually but makes zero sense to the end user. It seems like tabs are opening and closing randomly as you navigate around. You guys need to do some real user experience testing with some real web developers before springing huge UX changes like this on users. I'm sure there are UX professionals who would be happy donate their time if they knew their conclusions would be given credence.
[...] wrote a good introduction to the new activation model awhile back and you may find it useful to understand the differences between the way 1.3 and 1.4 [...]
[...] Simplified panel enablement, minimize controls, and site activation, [...]
Agreed... please bring back the site-specific enabling and do away with this new "feature"...
Complete ditto to #3 Luke Maurer.
This is a very significant change, and it took me some time to find *this* page to explain it!
I know that keeping Firebug at bay during 'normal' browsing is important, but when you're expecting it to work like before and it doesn't, it really cramps development.
If the enabled/disabled site list(s) are hidden further down somehow, I could handle the change. If the effect of opening or closing the Firebug panel could modify the lists, great - just ask me before you do that. But if the lists are GONE, it's painful.
The new Net panel stuff is nice though 🙂
I have reverted to Firefox 3.0 and Firebug 1.3 just because of this. It just doesn't make sense!
[...] We’ll just look at the activation part here. See Honza’s post for more info and the panel enablement. [...]
UI fail.
Wow, this is bad. For one thing it was fine (possibly great) before. I commonly want to watch some activity in the console then check out what happened in the net tab (or vice versa). Now I have to reload the page to view the second panel (which in the worst case scenario may not yield the same results). Am I missing something or is there some way to have more than one panel working?
This is the worst ever version of Firebug, absolutely unusable.
Switched back to 1.3.3
Epic fail.
[...] more about during the coming months and it still causes some users pain. Honza wrote an excellent introduction to it, which I’ve mentioned here [...]
I'm going to have to downgrade my version of *Firefox* just for Firebug 1.3, because 1.4 is incomprehensible and unusable. This tool has gone from something that was previously a joy to use to a daily recurring headache. As a side note, the amount of hostility in your discussion list is unbelievable.
Changing the X to turn off or deactivate Firebug instead of minimize it really through me off -> http://www.russellheimlich.com/blog/firebug-gets-a-little-buggy/ That's been my only gripe so far.
I like the added polish on the graphs in the net panel as well as the other small fixes.
Boooo!
But seriously, Firebug is killing FF when enabled on many pages. The previous model where settings where applied per-domain were perfect. Who wants FB enabled for all domains anyway?
I'll have to agree with the commenters above: fail.
I'm sorry to say I have to add my vote to the users saying this change is, frankly, terrible in regards to usability. The above post indicating that this change was actually made to make things easier really comes as quite a shock to me.
I really do not understand why this is not site specific, or at least having the possibility of this...
this release is killing people, I hope it will turn back to the way it was
Add my vote to the people who find this new UI a real headache - for web development it just no longer works, i've tried every combination of settings. My old workflow was:
1. I have a site to debug, enable firebug for this domain.
2. reload a page and watch the net panel show activity (in 1.4 it keeps disappearing, every reload/click navigation)
3. Muck around with CSS/JS - but again the panel keeps disapearing.
Well, I finally found this page, which unfortunately confirmed my worst fears. I've been fighting 1.4 activating/deactivating/reactivating seemingly at will. But to find out that the per-site stuff is totally gone is a heart breaker.
Firebug is (was?) my number one tool, hand in hand with the Web Developer toolbar, for site development and troubleshooting.
Developer(s): *Please* consider adding the original (better!) functionality back in at least as an option or alternative to this new (worse!) system.
Laker
"The road to hell is paved with good intentions", this its just another example. I'm hoping the devs will acknowledge the problem and somehow add the missing functionality in future releases.
ditto^e99999 wow what a mess. did you even bother to ask real users?
Silly change. I'll tell you why, it's killing off firefox for web developers. Here's an everyday situation;
I'm developing web applications doing lots of JavaScript, profiling etc. Then I open up googlemail, it hangs big time - I've forgotten (again) that I've got firebug enabled, I eventually get control of my browser back and quickly turn it off to do my email checks.
Then I go back and turn it on. Later on in the day I notice the browser is slowing down, I've had to reload my firefox window earlier as it was getting slow. Evernote and googlemail are working away in the background again, but firefox is logging all the calls whilst I'm developing. The browser again grounds to a halt and I have to endure another 30 second wait to get control back again. Turn it off for all web pages.
Now I'm forced to use safari over firefox.
This is not simple problem, it could quite easily be the downfall of firefox. We as developers get used to the fast responsiveness of webkit browsers and recommend our friends use it too, and why wouldn't they? They don't need the features that we developers have and we associate webkit with speed.
It isn't a bad idea, but it needs to have more flexibility.
AH HA, u changed things and hurt ppls feeling, not they try and hurt yours. Anyway, it was VERY confusing until I read this, not I know how to disable/enable firebug again, so no biggie. I accept the changes without having to slander firebug. It's still the beset, lightweight, and my favorite web dev helper and best friend.
However, I do miss the simple option to disable by domain, as many other fellow users have concurred.
I agree with #23 Luke. Please include an option to use the old behavior of activation.
Though firebug is a great tool, this activation headache makes it really annoying to use now.
I agree with #2... I came across the same problem with the AJAX calls not showing up just because I'm on a different tab. This is really frustrating as I have to keep everything open, sometimes on many different windows... defeats the purpose of having tabs in firefox.
I also like the old way of manually disabling firebug for certain pages. This new method is buggy (enabling on one window/tab seems to often enable it for all pages!) and unintuitive.
I hate new firebug for that. Please, change that back because it's always fucking me. I'm an advanced user and programmer and I really can't understand this.
The Firebug blog turned off comments... I wonder why? Also have you seen the Google Group threads about this, and the replies from the person/people maintaining Firebug now? What a bunch of assholes...
So I came here to vent my anger at Firebug's inability to understand which sites I want enabled/disabled, because I don't want to be subjected to a bunch of snarky comments about how I don't know how to use Firebug or file bug reports.
I followed directions... updated to the latest version, and it doesn't work. Obviously other people are pissed too.
It always gets turned on for GMail, which causes GMail to take 30 seconds to load. I could just use "Basic Html" in GMail, and just take the performance hit from other sites... but I have a new workaround...
Stop using Firefox for web-browsing. Use Chrome for web-browsing and Firefox for web development only. I never thought an extension could be so bad that I was forced to a different browser... but yeah, that's what happened.
Followups here please:
http://www.softwareishard.com/blog/firebug/how-to-enable-and-disable-firebug-15/
This new enabling/disabling mechanism is VERY VERY awful.
While on amazon.com (which runs like a dog with FireFox enabled) one should simply need to right-click on the FireBug status bar icon, and choose "Disable FireBug on amazon.com" or, conversely, "Enable FireBug on amazon.com".
Period. End of story.
Please fix this horrendous new "feature".