Archive for the 'Firebug Feature' Category

Firebug 1.6a11

Friday, May 21st, 2010 has Firebug 1.6X.0a11. This release is dedicated to Sebastian Zartner who recently joined the Firebug Working Group and has been working on our bug list.

  • Honza implemented console.table so source like this:
  • var family = {};
    family.header = ["First", "Last", "Age", "Desc"];
    family.mother = new Person("Susan", "Doyle", 32);
    family.father = new Person("John", "Doyle", 33);
    family.daughter = new Person("Lily", "Doyle", 5);
    family.son = new Person("Mike", "Doyle", 8);
    family.mother.desc = "mother";
    family.father.desc = "father";


    More examples are available in our console/api/table test page. This feature was suggested by Patrick Mueller who works on webkit based on a similar feature implemented in FirePHP by Christoph Dorn.

  • Disabling break on next error and  debugger; keywords. When you hit these in the debugger you now have the option of replacing them with a disabled breakpoint. The debugger will not break at these lines until you remove the disabled breakpoint:
  • You can also see the forward and back arrows Honza added in 1.6a10 in these screenshots.

Of course we have bug fixes, mostly around problems I created with the persistent breakpoints feature.


Please post comments in the newsgroup.

Firebug at WWW 2010!

Thursday, February 18th, 2010

Our paper Dynamic and Graphical Web Page Breakpoints was accepted as a technical paper for WWW2010 in Raleigh, North Carolina, USA, April 26-30.

We updated the paper with the latest 1.6/1.5.1 screen shots. Most of these images are also in the breakpoints demo page. A few images from the demo did not make it into the paper and they still show the 1.5.0 user interface.


Followup in the newsgroup please.

Event Listener View for Firebug

Friday, October 30th, 2009

Jan “Honza” Odvarko release our first version of “eventbug”, a Firebug extension to add support for inspecting event listeners.

  • Event panel shows all event types with handlers on the page, click the event type name open to see the elements and handlers
  • Side panels show the target list, element bound the the handler, and the handler source code.
  • New Events side panel in HTML panel, shows event handlers per element
  • Event handlers linked to Script panel to show their source code.

Honza has screen shots and more details in his blog post.

We need your help to get this feature into Firefox 3.6!

Here is how you help:

  1. Install the alpha versions of Firefox/Firebug/Eventbug using Honza’s instructions.
  2. Try the Event panel on your site.
  3. Report your findings on the Firebug newsgroup.

The code is now in Firefox 3.7a. We will use this as evidence to support the risk/benefit analysis for shipping the event support in Firefox 3.6 when we talk to the Firefox release team.


EU MozCamp 2009 Slides

Monday, October 5th, 2009

Jan ‘Honza’ Odvarko has posted his slides from his Firebug talk at EU MozCamp 2009. Includes good introduction to features of our upcoming Firebug 1.5.


Please post followups to the newsgroup.

Eventbug Rising

Friday, September 18th, 2009

Honza and I have been working on a new Event panel for Firebug, based on the work by Olli “smaug” Pettay and the Firefox team over on Bug 448602. The events panel will list all of the event handlers on the page grouped by event type. For each event type you can open up to see the elements the listeners are bound to and summary of the function source. The attributes for capturing and Allows-Untrusted are also listed.

The element is link to HTML panel. If you hover on the element in the event panel the corresponding element in the page is highlighted. The function is linked to the Script panel so if you click on it you can, for example, set a breakpoint.

Here is a sneak peak at the UI:


At this time we don’t know what version of Firefox will support this feature, but you can guess that we are begging whenever we get a chance ;-).


Please followup in the newsgroup.

Firebug Inspect Feature Implementations

Saturday, August 15th, 2009

Since “inspect” is a core and widely used Firebug feature, I wanted to give an update on its status and plans.

The short version: We think Firebug 1.5Xa21 has most reliable inspect ever (esp. on FF 3.5) and we have an even better one in the pipeline.

Some details now. There are 4 versions of the inspect feature:

  1. Joe’s original inspect, plus some minor tweaks. This was in Firebug 1.3. Lots of success; lots of bug reports.
  2. Mike Radcliffe’s ‘body-tag’ version, in Firebug 1.4. Solved problems of Joe’s version; also lots of bug reports.
  3. Mike Radcliffe’s Joe-fix-pack version, in Firebug 1.5. Avoids the body tag problems; no track record yet.
  4. Mike Radcliffe’s Canvas version: Total new approach, in progress.

The first three versions work by injecting content into the web page.  We try not to collide with page content, but the web is so big and various that some collisions happen.  So some pages have inspect offsets, failures, or (rarely) the page is mis-rendered. Because the tags used in 1.3 and 1.4 are somewhat different, 1.3 might fail on cases where 1.4 works and vice versa.

By unfortunately coincidence, changes in Firefox 3.5 make inspect with 1.4 break more often. So Firebug 1.4 on Firefox 3.0 is better than Firebug 1.4 on Firefox 3.5 for inspect. This is what sparked the 1.5 version.

So why don’t we put the 1.5 inspect into 1.4? Because our ability to test inspect is limited give the huge variety of pages.  Users who have problem with 1.4 on Firefox 3.5 can use Firebug 1.5a21 now and we don’t risk breaking users who do not have a problem.

And what about that canvas version? The idea is to create an inspect that does not inject elements in the page. Is it possible? Stay tuned…


Followups on the newsgroup please.

Give your eval a name with //@ sourceURL

Tuesday, August 11th, 2009

The first Firebug feature I worked on was a whopper: eval() debugging.  One of the challenges is how to name the source code buffer.

By default Firefox names the eval() buffer using the containing filename. This is a disaster:  it’s the debugger equivalent of overstrike: eval functions overlap orginal functions.

Coming up with an alternative is not so easy. The name has to uniquely identify the buffer to support breakpoints and yet be understandable by developers. The Firebug default is to compute an MD5 hash for the buffer then show the developer a string related to the calling file and the source.

Firebug also supports developer-named eval() buffers: just add a line to the end of your eval(expression) like:

//@ sourceURL=foo.js

This makes the source appear to come from the calling domain at file foo.js. The syntax of the line needs to match this regular expression:

const reURIinComment = ///@ssourceURL=s*(S*?)s*$/m;

sroussey points out that this feature has recently been added to Webkit so it should also work in Safari.


Followup in the newsgroup please.

StatusBar Icon in Firebug 1.4a23

Wednesday, April 29th, 2009

Firebug 1.4.0a23 is out.  It includes couple of additions to the status bar icon context menu.

status bar context menuHere’s the full line up now:

  • Open Firebug in New Window. aka ‘detach’. as before.
  • Clear Console. Well it’s been there since 1.o…
  • Reset All Firebug Options. Changes all of the Firebug options back to their default values. We use this in testing Firebug, so it may help you if something odd is happening. BTW, no confirm on this one. I’d like to have a confirm window that listed all of the options. Someday.
  • Enable All Panels. Enables Console, Script, and Net panels. Extensions could use it too. Does not reload the page.
  • Disable All Panels. opposite of enable.
  • Off for all web pages. Closes all Firebug instances, erases all memory of which pages had Firebug open in the past. Also used for testing; also wish it had a confirm.
  • On for all web pages. Opens Firebug on all pages; does not use the page-annotation for remembering which pages are open.
  • Minimized: the list of pages with Firebug active but minimized. Clicking on an entry will select that tab and restore Firebug into the browser.

status bar tooltip
To go with the new Context menu is a new Tooltip. As before the Firebug version is available here. Also the activation status of the panels. If all three panels are off, the Firebug icon should be gray. Otherwise it should be orange (as before). Then the number of detached (none in this case), minimized, and total Firebug web pages are shown. The number of minimized pages should match the list in the context menu.

Please post follow-ups to the newsgroup.


Minimizing Firebug 1.4a22

Tuesday, April 28th, 2009

We are very close to the end of Firebug 1.4 features. I am just adding a few more to deal with problems raised by users of the some new features.

Now on the upper right hand menu will be a new button, a down arrow to mean “Minimize Firebug”. introducingminimizebutton Use this when you want the Firebug UI out of the way but not off on the page.  The up arrow continues to mean detach Firebug into a standalone window, but you can also think of it as “Maximize Firebug”, since mostly folks use it to get more screen size for Firebug. The [x] means “Close Firebug” as  always, but now this button has more importance: from now on in 1.4 this is the way to close Firebug on a page.

Did you catch that: The red [x] is the way to close Firebug on a page.

The reason to pay special attention is that we are also changing the behavior of the Firebug status icon button: when Firebug is open, the button will minimize rather than close Firebug. This is similar to older versions of Firebug, so it will only be a surprise for folks who use the alpha versions of 1.4.

If you start with Firebug closed, the status icon will be grey: greybug If you click it, Firebug will open and (if you have the panels enabled) the icon will be orange:orangebug Another click on the status bar icon will minimize Firebug; the icon will remain orange since Firebug is still running.  More clicks will alternate between restoring the Firebug UI and minimizing it.

The description is a bit long winded and I’m not a fan of context-dependent UI operations, but this sequence is what Firebug users expect, especially designers who actually want to look at the web page, go figure.


Please follow up with comments in the newsgroup.

Firebug 1.4 marks getters

Saturday, April 18th, 2009

Since we already had a bug report about this, I guess I better mention that Firebug 1.4 marks properties that are implemented with getter functions by prefixing the property name with ‘get’:


Soon we hope have a context menu item to link to the function definition.