Here’s peek at new features in 1.4 as of a7.

Sticky debugger controls. When you hit a breakpoint in Firebug the Script panel comes to the top and these controls become active.  But if you change to the Console or Net panels, get deep in debugging, its easy to forget you are stopped.  In 1.4 these controls will show up in every panel while they are active.

Case-insensitive search.  For source searches, you can type all lower case and the search will be case-insensitive or if you used mixed case the search will require case matching.

Break on next. When you are not stopped in the debugger but want to break on the next Javascript function, click the pause button. It will arm itself and flash until some Javascript runs. This could be a button click, AJAX callback, or page load. Still experimental as of a7.

Three invisible features:

1. Avoid scroll on single step. Makes the UI less bouncy
2. Stay on debugger. Internal control to reduce exotic Firebug bugs and improve performance
3. Avoid MD5 on eval(). If you don’t set breakpoints in eval() code, you don’t pay to hash the buffers.

This last feature should make Firefox faster when you are using Firebug but not breaking in eval() code.

(I prefer follow ups on the Firebug newsgroup)

getfirebug.com/releases has Firebug 1.3b4 and 1.4a7.

This may be the last 1.3 beta, it has fixes for Firefox 3.0.4 using the new nsITraceableChannel API.

More about 1.4 next time…

Hello world! This is just a quick note describing this very blog you’re looking at. Its sole purpose in life is to provide a place for Firebug developers to leave feedback about what they’re working on, suggestions on how to better use Firebug or changes to internal APIs. I can also see this becoming a place to highlight new or popular Firebug extensions as they emerge or we learn about them.

As always, public discussion, feature requests and bug reports should go to the google code project page. Speaking of discussions, it’s fine to comment to individual posts here, but for meatier discussion to a potentially wider audience, traffic should be directed to the google group.

I’m going to try to mention tidbits of info about Firebug implementation in this blog, under the category Firebug Internals.  They won’t make any sense unless you are looking at the Firebug source.

I was talking with Mike Collins about Firebug events and he was puzzled about the “ShowContext” event. Firebug modules (common logic units) get this event twice for every page load. Why?

ShowContext is intended to signal that the Firebug UI is now going to be shown to the user. When should that be? Well as soon as possible is mostly the answer. Certainly you want the Firebug UI to come up before the onLoad event for the page in case the developer needs to debug things that happen before that. Thus one ShowContext is sent as early as possible after initContext. But Firebug also wants to update the UI later and it uses ShowContext again at that point.

Firebug extensions then need to use ShowContext to refresh their view based on any data that may have changed. Roughly speaking a module will see initContext, showContext, loadedContext, and showContext as the page loads.  We’re hoping to make this more certain when we get support for document load started events.

After a long delay, the Firebug Development Blog is back. Thanks to Rob Campbell for getting us on line.