Archive for the 'Firebug Internals' Category

Crossfire: Multiprocess Cross-browser Open Web Tools Protocol

Thursday, April 28th, 2011

Most Web developers write for all Web browsers, but their development tools only work on one browser. To the extent that browsers are standard, this works out.  Except when it doesn’t. Then you are stuck trying to use the unfamiliar development tools in another browser. Moreover, some browsers have better or different support for development tools. The Crossfire project aims to provide a way for development tools to work cross-browser.

Michael Collins and I wrote a paper describing the Crossfire protocol and system for Splash/Wavefront. A PDF preprint is now available. We describe both some aspects of the remote protocol and discuss the evolution of the Firebug source code into client/server code using Crossfire.

The Crossfire project benefits from many contributions, so I encourage you to read the Acknowledgments section first and to add your name to that list by pitching in to help us push this project over the finish line.


Please post comments or suggestions on the newsgroup.

Make link files in Firefox 4.0 read-only, use -purgecaches

Wednesday, November 10th, 2010

This post is for folks who work on Firefox 4.0 extensions.

In trying to track down some Firefox 4.0 issues today I discovered that my Firebug copy had been overwritten by Firefox. Ouch.

To develop Firebug we use a ‘file-link’ , ‘file-proxy’  or  ‘symlink’ feature of the Mozilla platform.  We create a file in our profiles’s extensions/ folder called and in that file we put the file system path to our development directory. Firefox reads this like it was an installed extension.  Then when we change Firebug source, we just kill and restart Firefox to test and debug.

In Firefox 4.0 these file-proxies can be silently overwritten. Three ways I know that can be avoided:

  1. Insure that your dev version always has a newer version,
  2. Change your install.rdf to add <em:unpack>true</em:unpack>,
  3. Make your file-proxy file read-only.
  4. update: Set the pref extensions.update.autoUpdateDefault to false

The first option means you can’t go back and check any older version’s behavior. The second one means that you have to have a different install.rdf for dev and release. So I guess it’s #3. Update: Thanks to hints by Blair McBride and Colby Russell, option #4 is the winner. I set this in Chromebug’s defaults files so it will always be on.

And just in case you missed it: you also have to add the command line option -purgecaches to get any extension changes to be picked up.


Firebug Metamorphosis

Sunday, October 24th, 2010

The upcoming release of Firefox 4.0 will have built-in development tools. These built-in tools exist to compete with other browsers, but of course the other browsers compete with Firebug, so it goes around.  They all have more design and development resources than Firebug and they all have a built-in advantage: they’re built-in!  Our little Firebug project must adapt to this reality if we want to continue to make a difference.

With no doubt, the Firebug team can take credit for changing the world of Web development. Now can we avoid becoming a victim of our own success? Simply working harder to compete is equal to giving up. Instead we have to raise the bar!

Therefore we are taking three new directions beginning with Firebug 1.7.

The Cross Browser Tools Initiative
  • splitting Firebug code into front and back end piles,
  • merging the Firebug Lite and front end Firebug-for-Firefox code bases,
  • developing support for full Firebug on other browsers, including mobile
Investing in fundamentally new tools
  • a new approach to Javascript debugging to supplant breakpoint debugging,
  • create a new CSS debugger.
Reaching out to our community.
  • shifting from open source to collaborative source to create closer cooperation between Firebug core and extension development.,
  • asking Firebug users to donate in proportion to the impact Firebug has on their work.

These are major changes. Firebug’s internal systems will be re-organized and placed in new wrappers. Firebug will grow powerful new capabilities. We will create new relationships to thrive in our new environment. It’s a Firebug metamorphsis.

I will be posting more details on these areas in the next few weeks.


Please post comments on the newsgroup.

Firebug Dreams

Thursday, March 18th, 2010

Some ideas for Firebug beyond Firebug 1.6 and 1.7:

Javascript edit and go: Currently you can edit the DOM values, CSS rules, and HTML elements and attributes. But you can’t edit the Javascript. So JS developers miss out on the quick-let’s-just-see model so popular and powerful for other users of Firebug.

Automatic or Query-based Logging: Now we have to edit our Javascript to add console.log() statements. Some times we just want to know: what code runs when I do this? A simple way to summarize the execution path would be automatically inserted console.log() calls on every function call or every call matching a pattern and so on.

CSS by Example: If you know CSS, Firebug let’s you into tweek a page to perfection. But what about the rest of us? Every time I mess with CSS I have to spend most of the time reading docs or looking up examples. I’d like a “for example” mode that shows me just a bunch of different thing CSS can do to an element.

CSS Connectors: Actually I don’t know how to name this or exactly what I want. I do know that want fluid layout but I don’t want to read forty different ways to do three column layout again. Maybe we can extend the Firebug inspector to show the box hierarchy and/or the boxes that the selected box is directly related to.

Live Object Sites: By a large margin the most requested feature for Firebug is Issue 179, Create a unified patch from CSS changes. As you can see in that issue there are two Firebug extensions that solve this for some cases. Our work on 1.6 should make those extensions easier to install and update. But this is just the start: we want every kind of edit to be synchronized. Maybe should also explore more aggressive approaches like Dan Ingalls’ Lively Kernel.

Memory Analysis: As Web applications grow and grow we are increasingly running into memory limitations. Analyzing memory usage is hard; I think we need several different approaches. We are looking at trying to use a Memory analyzer created by Dion Almer and Atul Varma and their colleagues. It gives you the number and sizes of objects. We’ve also discussed a “high memory” analyzer,  part of a JS function profiler that would just tell you which functions bumped up the high-water mark, a very fast way to pinpoint a serious problem. Another critical tool would find back links for a given live object: why isn’t this one being garbage collected?

Widget-set Debugging: Many Web pages these days are built on toolkits like Dojo, ExtJS, jQuery, or Scriptaculous. Users at the toolkit level think in terms of widgets and events of the toolkit, so debugging at the HTML and DOM event level is tedious and confusing. Firebug should have direct support for toolkit debugging.

Code Coverage: Lots of folks use test-driven development or at least have some test suite for their code. We need some easy to use ways of finding out what parts of the code are not being touched by our test suites. We also need to know what  HTML and CSS does not actually contribute to the page even if it is shipped to users.

Integrated Debugger Environment: Firebug should support multiple simultaneous views of more than one panel and have better integration support with editors and Web servers.

FireCrystal and WhyLine: Stephen Oney in Prof. Brad Myers’ group at CMU has a very cool prototype for a graphical tracing tool called FireCrystal; it animates a time line with snap shots of the Web page so you can find out when a particular UI change happened or study the graphical update in slo-mo. A former student of Prof. Myers, Andy Ko, now a Professor at U Wash., created a Java debugger for graphical applications that supports query-style debugging. I’d love to explore the potential for these ideas in Firebug.

Finally, I am collaborating with Salman Mirghasemi and Prof. Claude Petitpierre from Ecole Polytechnique Fédérale de Lausanne, on Salman’s new approach to conditional breakpoints (well that hardly does the justice to the idea) and we hope to bring some of these ideas into Firebug.

The Firebug issues list has a lot of other great ideas for enhancements.  If you have a cool idea or suggestion not on one of these lists, please let us know in the newsgroup.


Firebug Reflections

Wednesday, March 17th, 2010

The third anniversary of my first Firebug contribution is coming up, so it’s time for a little reflection and dreaming.

We’ve come along way since Joe Hewitt unleashed Firebug 1.0.  Arriving at the start of the Web 2.0 revolution, Firebug helped shift people from thinking Web 2.0 was a fad to realizing Web apps can be real. Firebug had to grow up in a hurry while we still did not understand the code well and certainly didn’t understand Firefox.

Firebug 1.1 wasn’t really meant to be, used by a few dedicated and helpful folks. So Firebug 1.2 was our first real release beyond Joe’s original source. Behind the scenes we had lots of extra work to close a security hole in Firebug.  At the time we could not tell anyone: too many users were exposed.

Firebug 1.3 was originally planned as a stop-gap release, but thankfully it was pretty solid, because Firebug 1.4 started off as a bizarre disaster: a lot of unpopular UI changes masked a serious UI bug that took weeks to discover. Firebug 1.5 went a lot smoother, partly by luck but mostly because we finally have a solid test suite and working debugger for our debugger.  Firebug 1.5 just entered the history books; we’ll know in a few months how we did.

Some people use Firebug as an inspection and tweeking tool; some use its console or net panel; some use just the Javascript debugger. But for most users the real power of this first ever Web debugger is synergy.  No combination of independent inspectors, consoles, net-traffic analyzers, and debuggers provides the same level of support for developers. Pivoting between panels and using one view to trigger action in another is how Firebug Ninjas work.

The world of Web development changed in three years. Other browsers gave up on small independent tools , they now have debuggers that look and act an awful lot like Firebug; there are even another browser now and it comes with a Firebug-like debugger built-in. While I am hardly unbiased, I think Firebug remains the best of the bunch, both in terms of overall design and in terms of a rich and appropriate feature set. For that we have a lot of  talented and dedicated contributors to thank!

But what about the next three years? I’ll do a little dreaming in my next post.


Follow up on the newsgroup please.

Plans for Firebug 1.6 and Firebug 1.7

Friday, January 22nd, 2010

The Firebug Working Group has some initial plans for Firebug 1.6 and 1.7. The short versions:

Firebug 1.6

Target April 2010, Firefox 3.6 and 3.7: Better support for Firebug extensions

Firebug 1.7

Target Sept 2010, Firefox 3.7: Internal Re-architecture


Please post follow ups on the newsgroup

Jetpack in Chromebug

Wednesday, January 13th, 2010

I wanted to learn more about jetpack so (duh) I tried to debug a jetpack.  In case you’ve not heard,  jetpack is a Mozilla labs project to support easy, rapid development of Firefox addons using Javascript operating in an HTML rather than XUL world. You should try the tutorial, it really is easy and rapid!

Well, as long you don’t need to debug. Seems like the debug story is writing to Firebug’s Console.

Can we have a ‘jetbug’, a Firebug-like experience for jetpack? To start we’d need to understand what is jetpack. In part it is a Firefox extension: we should use Chromebug to investigate.

I ran the jetpack ‘boom’ tutorial from the about:jetpack URL. It is very short:

 html: "Boom<i>!</i>"

Then I inspected the “Boom” addition to the status bar:

In Chromebug we can see the implementation markup:

<statusbarpanel contextmenu="_child">
<iframe type="content" src="data:text/html,Boom%3Ci%3E!%3C/i%3E"
style="overflow: hidden; height: 16px; margin-top: 2px; margin-left: 4px; margin-right: 4px; width: 30px;">

So they put an iframe into the status bar to support HTML! Cool.

Next I want to find the Javascript above.  I did not get there yet, because Chromebug got confused by seeing a scope that was not a Window or BackstagePass. After some uh, logging based debugging of Chromebug, I can now see the Jetpack “Sandbox” object:

The console looks like an interface to Firebug. You can see the jetpack object used in the tutorial. Also in the sandbox is some jquery stuff and system functions.

Unfortunately there are ten other sandboxes whose role I don’t understand and I can’t find the source shown above. But it’s a start.  (Chromebug 1.6a3 will include what I’ve learned so far).


Followups on the newsgroup please.

Firefox shifting support from extensions to jetpacks

Saturday, January 9th, 2010

Following a long discussion about Firefox Themes vs the new Persona technology, Mike Connor from the Firefox team explains on his blog why Firefox plans to migrate developers from the current theme and extension systems to personas and jetpacks.  Since we are a Firefox extension, you might wonder How will this affect Firebug?

I don’t think these changes will have a big impact on Firebug.  Firefox will continue to support extensions while the jetpack technology matures.  We can adapt as we go along.

I don’t expect we will adapt towards the jetpack solution however. Jetpacks are designed to broaden the number of addons beyond the current 8000; they make small add-ons much easier to build and maintain. As a very large add-on with a huge API contact area over the mozilla code, Firebug is way out of their design space.

Instead I expect our adaptation will be steal some ideas from jetpack and apply them to Firebug and to move away from aspects of the extension system that Firefox wants to drop first. Hopefully we will hear more about what is on the hit list. Based on the discussion linked above, XUL overlays and the install/update technology would be on the list.

We can live without the XUL overlays.  The vast majority of Firebug code is HTML, CSS, and Javascript. The panel tabs and tool bars are XUL/XBL but the overlay part is just two files.  We could adapt Firebug’s domplate technology generate the XUL.

Similarly the install/update technology is not a big deal. In fact I am currently working on an alternative solution to the add-on compatibility problem. However, I am trying a different strategy than the jetpack team because I have different design goals. I am aiming for users to see only a few choices, by bundling Firebug extensions together. (I’m using the cutesy name ‘swarm‘ for these bundles).  I want users to know that the extensions in the swarm work together (or at least don’t break Firefox or Firebug).  So the swarm will be co-tested with Firebug and the entire swarm will install and update as a unit. I believe this will be a big boost to Firebug extension developers as well as providing our own alternative to the Firefox update technology as it slowly fades away.

In the big picture, the evolution of Firefox’s extension system does not stand out as a significant worry.  We have the shift of Firefox to multi-process, the rising need for debugging mobile web, and many untapped and exciting new features to focus on.


Followups on the newsgroup please.

Performance problem in Firebug 1.5 (and probably 1.4)

Wednesday, August 26th, 2009

I spent the day looking into

  • Issue 2187: firebug causes memory leaks

I still don’t know if there is a memory leak (or even how to find it if there is), but I sure found a problem. When Firebug’s Error module is active and we load, it takes about 90 sec on Firefox 3.7 nightly build. With the Error module inactive, it’s about 6 seconds.  (On a Firefox debug build the load never completes). The memory goes up dramatically, so my guess it that this is the source of both the excessive CPU time and apparent leaks. Note that does generate a huge number of errors.

For now the only workaround is to disable the Firebug Console (with the mini menu on the Console tab). Firebug 1.5a22 will have a slightly better workaround, it will disable the Error module if you turn off all error and warning settings in the Console.

To find the problem itself may be hard. Chromebug’s profiler did not work, so I’ll fix it and see if that gives some hints.  There is not a lot of code in Firebug’s Error module, so I’m surprised that is the culprit.

Update: the problem was tracked down to the code that assigns error messages to the correct window. In looking through all the URLs for a page, you need to look for imported style sheets.  That is done by looking through all of the rules in a style sheet for import rules. We processed 13,000+ rules, requiring ~1 sec to process all of them. This was done once for each of the 100 errors. So we get 90 sec load time.  A bug was causing us to revisit the same style sheet 6 times  (gmail uses 2318 rules); cutting off the rule search when imports can no long be possible and caching the results brings us back near zero, so the total load time  is now around 6 sec.


Follow up on the newsgroup please.

Watch us while we work…

Tuesday, August 11th, 2009

The Google Code project Firebug uses now supports a feed of SVN changes: Subversion commits to project fbug on Google Code.

Ok, I know, not that exciting. But people have asked it.


Please post followups to the newsgroup.