Archive for the 'Firebug Feature' Category

Firebug 1.4 Auto-suspend and Simplified Activation

Wednesday, March 25th, 2009

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.

Please post follows to the newsgroup.

1.3: Viewports on Script Panel

Thursday, February 19th, 2009

All of the discussion about Bespin’s choice of  Canvas for source code editing, reminded me to talk about one of the invisible new features of Firebug 1.3: the Script panel is now implemented with a ‘viewport’.  By that I mean that only the visible lines of the source are rendered.

If you have 40kloc in a Javascript file (yes those extJS files do that!), the pre-1.3 Firebug would try to render all 40,000 lines in to HTML. Each line would require about 10 DOM elements, plus they have attributes.  That means we are up to around a million nodes.  So as soon as you try to view that monster JS file, Firefox starts to burn CPU while you sit and watch. With the viewport solution we only build 20 lines, a factor of more than 1,000 less!

Of course the viewport has to be updated dynamically for scrolling and other movement.  If you use 1.3 you will see that the Script panel is not as smooth or fast as one would like.  1.4 adds a number of improvements mostly around avoiding extraneous updates.

Right now the 1.4 script panel is fast enough, if not blazing. That makes it unlikely that we would invest in a canvas alternative until we examined the performance issues and determined that the problem was related to HTML rather than some other issue in Firebug.  Another consideration for a large code like Firebug is complexity: the viewport code is harder to maintain but I guess not as hard as a canvas solution.


Tabs UP!

Tuesday, February 17th, 2009

Check this out: Curtis Bartley has  re-organized the Firebug UI to put tabs on top:

Curtis Bartley's prototype Firebug UI with tabs on top

So now we need to know: is this major reorg of the UI going to cause users problems? Please try his prototype and let us know.

Firebug Feature? Tagged ‘firebugged’

Tuesday, February 3rd, 2009

For Firebug 1.4 we want to try yet again to improve the enabled-panels user experience. The 1.2/1.3 solution is too complex for users and too hard for us to maintain.

One idea is to turn on the resource-hungry features only for web pages that Firebug is open on.  If you are debugging, you have your site selected and you have Firebug on. If you wander off an read your email, you don’t have Firebug up. Firebug would be on when you are debugging and off when not. Makes a lot of sense (even if it is not as easy to implement as it sounds).

Part of implementing this is to remember what pages you had Firebug open on. And one way to implement this remembering thing is the Firefox Places tagging API. By tagging pages as “firebugged” when you open Firebug on them, we can check this tag when you open that URL later.  Maybe you don’t like us to mess with your tags, I don’t know.  As part of the trade off,  you can type ‘firebugged’ in to the location bar and get a list of all pages you use Firebug on:


That seems pretty cool to me.  (Note that the top link here is a page I opened Firebug, then closed it, seems like Firefox is confused).

Still investigating this idea, comments welcome.


Firebug Feature: Without Security Issues

Wednesday, January 28th, 2009

Firebug 1.2+ in Firefox 3 provides no known path for malicious attack by rogue web sites.

Recently Wladimir Palant wrote a nice long post on Displaying web content in an extension – without security issues. In the lead paragraph describing security vulnerabilities he points to a really old posting about an old version of Firebug:

pdp discovered a similar issue in the Firebug extension that uses an HTML-based templating system and forgot to sanitize some input received from the webpage.

If you read through these ancient scrolls you will find Joe Hewitt’s post about the fix. But that fix was way back before version 1.0.5 was out, so none of that old stuff matters today.

While working on Firebug 1.2 we analyzed Firebug for security issues. As a result we reimplemented the Firebug console and command line and Blake Kaplan added new features in Firefox 3 to complete the process.

Firebug works with web pages in so many ways that we have to consider security issues all of the time.  We do take security seriously and we won’t release any version that has known holes.