Firebug 1.4 Auto-suspend and Simplified Activation
One of the features of Firebug we like least has been the enable/disable stuff. Joe Hewiit’s original 1.0 Firebug had a pretty simple blacklist scheme for disabling Firebug sites; mostly users thought it was fine. But when users tried Firebug 1.1, the impact on performance of the eval() debugging features was too large, especially for users focusing on CSS or HTML. But the biggest problem wasn’t folks using any particular debugging feature, it was users of heavy AJAX apps like gmail.
For Firebug 1.2 we added more options to control what parts of Firebug were active. These enablement controls were hard to understand and very unpopular. But no one was willing to give up their favorite setting either. And at least you could blacklist gmail to reduce the pain of having Firebug installed in your browser.
Firebug 1.3 made some UI improvements that helped make the controls easier to learn. But the real innovation in 1.3 was the introduction of suspend/resume. This was a global off/on switch which was simple and effective.I briefly experimemented with an ‘auto-suspend’ feature but could not get it to work before we closed 1.3.
In Firebug 1.4 we started with another round of fine-tuning. Then Steve Souders pushed for a more aggressively simplifed approach.
So for 1.4 we have ripped out all of the per-site controls and even the manual suspend/resume. Everything is now controlled by auto-suspend and the panels have only “enabled” or “disabled” settings. In the new model, if you can see Firebug, then its active. If you can’t it’s not.
We hope and believe that the new solution will be very natural: you’ll open Firebug and start working. If you don’t want Firebug on a site, close it. If you have Firebug open on a site and change tabs, Firebug will suspend. If you go back the the page you had Firebug open on, it will be open again and resumed. If you really want to have Firebug running on a tab that’s not on top, open Firebug in a new window (so you can see it, then it’s active).
The Console, Script, and Net panels will be disabled by default when you first start Firebug. You can enable them if you need them; once you do enable them they will be enabled for all sites you open Firebug on. You can’t mix and match sites and panels like you could in 1.3, but we think this is a rarely used feature we can live without. There is one surprise: enabling the Console also enabled the Script panel. We hope to fix this in Firebug 1.5.
The new activation is in Firebug 1.4a14 if you want to give it a try.
March 26th, 2009 at 10:51 am
@Maxx, hidden tabs can still be debugged with 1.4: just open Firebug on that page using Open Firebug in New Window.
March 30th, 2009 at 12:45 am
The new design feels natural to website developers. But I use firebug for logging and monitoring purpose (for both web pages and firefox extensions) so I’d like to still have an always on option. Using Firebug in a new window is OK except for the labor of switching windows…
March 30th, 2009 at 7:44 am
I’m finding the new design very frustrating. Firebug is automatically closing itself on every page load and by the time I get a chance to re-open it the ajax calls are already complete – meaning I never get to see them logged.
I don’t want firebug to ever close itself – if I have it open on one page, it should still be open on a new page. If have firebug open and I open a link in a new tab/window, the it should also be open in that window.
April 3rd, 2009 at 11:13 am
I’ve been using Fire bug for 6 months now and can’t say that I really noticed much of a difference from any of the upgrades since then.
What I would love to see though, is firebug integrated with IE tab because after using firebug to develop some websites I can honestly say there is nothing more frustrating than not being able to use firebug to debug a website that has an IE issue!
I think if this was done the world would be a much happier place
Regards
Craig
April 3rd, 2009 at 12:10 pm
I should point out – whilst I think Firebug lite is nice idea its implementation is clunky and not good to use. Its a good idea but so badly implemented at this point to be more of a nuisance than a help!
Regards
Craig
April 11th, 2009 at 12:54 pm
I think the best way to control enabling and disabling is just to have a button to the right of the firebug icon that you can flick green or red depending on whether you want it active when it is minimized
I’m sure other javascript developers will agree, but the two problems I have with the latest model is
1. If the firebug console is minimized then no errors will show up. I have used firebug a lot to flick between notepad / firefox and when it leaves “1 Error” at the bottom after I’ve shut it down and yet there are none it gets a bit confusing
2. Hiding the firebug console prevents the “console.log()” function from working so basically you can’t hide firebug without all of your code packing up and not working
April 21st, 2009 at 8:58 am
I have to say I was somewhat troubled to see the simplified enable/disable controls in 1.4. I do like the per-panel idea (though I was honestly rather satisfied with 1.3′s level of control), and the “disable whenever collapsed” approach does offer a feasible-in-most-cases alternative to the per-site whitelist, though I think I will still end up missing the latter.
However, the disable-whenever-collapsed behavior quickly blows away THE most frequently and immediately useful feature of firebug to me, which is being able to have firebug active while collapsed and notifying me of JS errors at any time. I find this very useful since I might not have any reason to have firebug open at the time, but something might still go wrong out of left field that I should know about.
Is there another way to get this at-a-glance error notification (without having to consciously go look at the error console) that I simply don’t know about?
All in all, this approach does make sense from a purely usability perspective; however, considering the target demographic of this extension, I really think it’s oversimplifying things at the expense of flexibility. Developers are power users, are they not?
May 26th, 2009 at 7:07 pm
When I open firebug console and click ajax request, the console can show the code in ajax reponse, but in browser the ajax cannot respond (looks keep loading).
I am using 1.4X.0a30. (on my firefox 3.5b4)
In my old version (1.3 with firefox 3.0), this works fine. I can open console and click ajax request, console can display me the code, and in browser the request responds correctly.
June 29th, 2009 at 5:25 am
Latest 1.4 beta in latest Firefox 3.5 rc while DISABLED in all ways possible still makes whole browser unresponsive while switching from any to any tab (it works 95% slower, I feel like I’m using some stupid secretary’s winblowz 486 box in year ’95 with some dumb antivirus in the background, not a high-end prof. optimized linux box; tab switching went from 10ms to 1,000ms!).
Older version 1.3… at least let me shut it down when I want to, the new “smart” edition won’t stop hogging the browser at nothing and will make it slow on all tabs all the time until I kill the extension and restart Firefox.
Can’t you just add some check box to make it forget that it is “smart”, and make it dumb like in the good old days when it knew how to get the fuck out from browser’s threads when I don’t need it’s presence? Stop making it act like spyware, I can smell anything that makes my box even 2ms slower than normal.
June 30th, 2009 at 12:23 am
I used my eyes because you can feel the difference between “instant” and 1 second.
It is reproducible so much i had to disable the extension to get Firefox back to normal speed.
Firebug in status bar had the gray (inactive) icon when the slowdown occured, I right clicked on it and selected to disable/off for all again, but it would still slow down tab switching to a crawl.
I am using 1.3 now and it is gray and not slowing down my browser. I guess it’s a bug in the mix of linux Firefox 3.5. rc build and Firebug 1.4 beta build.
June 30th, 2009 at 8:32 am
The bug reporting system is available here:
http://code.google.com/p/fbug/issues/list
jjb
June 30th, 2009 at 9:29 am
I am disappointed that you decided on this route.
Though the ability to choose which sites firebug was enabled on was less than intuitive, at least it worked once figured out.
Now I’m in a situation where I need to constantly enable and disable firebug, when really I just want it on all of the time except on google.com sites.
So now if I forget to disable prior to checking my email, I end up crashing the browser.
I wish you’d bring back the domain options, even if it has to be hard coded in a config file somewhere.
July 1st, 2009 at 2:08 pm
I agree completely with Chris and other commenters who are less than pleased with your new design. The new “smart” functionality ends up making things very confusing. It’s like the “smart” functionality in MS Word — well intentioned, but the in the end it just makes things less usable.
I just enabled Firebug in one tab and it automatically enabled it in all the other tabs — how is this desirable? Now my browser is super-slow because one of my tabs had gmail.
I’ve found similar things where if I disable in one tab it gets disabled in another.
All I want to do is use Firebug consistently on a couple sites I work on, while disabling it on all other sites. This type of whitelist is apparently not possible anymore. In the process of making things “easier” why would you take out very valuable functionality?
I really liked version 1.3 but apparently that doesn’t work with Firefox 3.5. Am I going to have to downgrade Firefox just to get a version of Firebug that is usable?
July 1st, 2009 at 8:26 pm
These issue are being discussed on the new group, http://groups.google.com/group/firebug.
jjb
July 3rd, 2009 at 11:03 am
Does anyone know how compatible Firebug is with Firefox for Mac? I’ve noticed Firefox already tends to be pretty sluggish on my Macbook.. Does it make it any worse? I’d really love the accessibility Firebug gives me, but I don’t want to risk making Firefox any slower than it already is..
July 6th, 2009 at 2:25 pm
[...] There has been some changes in the new version of firebug as compared to old 1.3 version. You can read the changes from their blog here FireBug1.4 [...]
July 15th, 2009 at 8:16 pm
I absolutely agree with B and Chris. This new version is nothing but trouble for me. It feels very counter intuitive since I expect firebug to operate independently in each tab. Instead, if I have two tabs open with a site from the same domain. I can’t have firebug be open for one tab and closed for the other. When I close firebug on one tab the other closes. Same with activating firebug. Very frustrating as sometimes I have a tab on a different subdomain (but same domain). Also sometimes I have two duplicate tabs with only one of them running firebug, but this is not possible anymore.
Please bring back the old behavior with Firebug 1.3! That interface feels much more intuitive and productive than the new “smart” interface.
July 15th, 2009 at 9:25 pm
Firebug > Firebug Menu > Options > Activate Same Origin URLs OFF
jjb
July 16th, 2009 at 9:40 am
Disappointing, pure and simple. I can no longer have two Firebug windows open so I can compare the styles in two different tabs. I click “Close” and Firebug keeps popping itself right back up. I click “Off” and I have to click “Close” too to make the thing finally go away. When I need it back, I have to reactivate it, then reload whatever page I was looking at. If I switch tabs to refer to something else while inspecting some style rules, the data goes away. The latest version, for me, is useless. Is there a fork of 1.3 anywhere that works on Firefox 3.5?
July 16th, 2009 at 11:30 am
To compare two pages, open two Firefox windows.
I don’t know what “Close” is in Firebug.
If you click “Off” and Firebug does not close, you probably have problem in your Firefox profile (config file). A new profile will fix it.
Switching tabs does not alter the data. Again I suggest a new profile.
I don’t know of any work on Firebug 1.3.
Our bug list is here: http://code.google.com/p/fbug/issues/list
jjb