~robcee/ field notes of a pyroentomologist, now 33% snappier!

Firebug Features Poll part 1

Last week I did a little informal polling via Twitter and Rypple asking users what their favorite and least favorite features of Firebug were. I will be the first person to admit that this isn’t exactly rigorously scientific as we only had a limited number of respondents from a possibly limited sample space (mostly English speaking Twitter users, ultimately connected to me with only a few levels of indirection). Still, the results were interesting in that they confirmed what I suspected about the majority of people using Firebug. I fully expect that there are other types of users who more-strongly gravitate towards other features.

Favorite Firebug Features

The break-down in exploding 3D pie chart format shows that 55% of users call the Inspector their hands-down favorite feature. In reality, this is probably closer to 73% if you combine the HTML tab which 18% reported as their favorite. When most people think “inspect” or “html” the next feature they describe is “being able to modify the CSS or see the layout of that node in the HTML panel”.

The next favorite feature is a tie between the Net panel and the Console. It’s possible that since I first collected the responses that the tie has been broken, but certainly not by much, and probably not within a suitable margin for error. The remaining 9% of responses were incomprehensible internet sounds. The cosmic background static of emerging consciousness.

How does this help? Well, it certainly tells us where we need to focus our efforts. We have seen a few errors with the Inspector over the past couple of years and think in version 1.5, we’re going to have most of them fixed. Annoying highlighter offsets and weird z-index issues should be a thing of the past thanks to work by contributor Mike Ratcliffe who came to us through the Firebug lite project.

I’m going to follow-up a bit later with the results of the “least favorite feature” question. They’re a bit harder to make sense of as the answers weren’t quite as obviously clear. Please let us know if this pie chart matches (or doesn’t) what you think is your favorite feature, too. This isn’t the end of the question — we’re just getting started.


New Firediff Alpha

Kevin Decker has posted a new version of the Firediff extension for Firebug which he’s calling “a major milestone”. While still not producing unified patches you can apply directly to your source code, it does create a “serialized version of the page state” you can then manually apply.

Firediff Snapshot + Diff Generation – In Case of Stairs

It’s still Alpha software, but it’s definitely getting there.


Firebug 1.5 and Firefox 3.6

… or, which version of Firebug should I use with Firefox 3.6, aka Namoroka?

We’re in a bit of a funny place with Firebug and Firefox 3.6. The Firebug 1.5 line is currently running better on Firefox 3.7 (trunk, mozilla-central) than it is on the 1.9.2 branch (Firefox 3.6, aka Namoroka). Fallout from a couple of bugs is causing some strange scrolling problems in Firebug and likely, a few other add-ons. Worse, we’re unable to edit anything in Firebug’s HTML and CSS editors.

That should change shortly. We’re waiting for a small patch in bug 511951 to land and correct these issues and make everything right again. I ran a build with this patch last night and confirmed that everything looks good. Our tests ran fully with no errors.

If you’re the adventurous type, you may feel like grabbing our latest version, Firebug 1.5a24 from getfirebug.com/releases and giving it a whirl. There are some changes, some improvements and more than a few bug fixes. See the evolving release notes for details.


Firebug Test Automation Phase 1 complete

Yesterday afternoon I posted a somewhat cryptic tweet:

Orange ftw. Blog post to follow. http://twitpic.com/gcizx

Well, here’s the blog post.

That little orange box is the first successful run of Firebug’s FBTest test automation tool through buildbot. It’s currently posting to the MozillaTest Tinderbox.

This is phase 1. We’re currently running Firebug’s 1.5 branch out of SVN against the latest linux build available in the Firefox 3.6 tinderbox builds directory. These are kicked off by SVN checkins to Firebug and FBTest. To give better coverage, and be somewhat more useful to Firefox devs, we’re going to run the latest built version of Firebug 1.5 against Firefox 3.6 branch and 3.7 trunk after a successful Tinderbox build. This will give us a known quantity (a Firebug that works in 3.5) testing against the different Firefox versions for incompatibilities. This should allow us to spot regressions as they happen in Firefox and report them much more quickly.

Once these are setup, we’ll create a separate Firebug tree, or if the sheriffs and drivers are amenable to it, drop a column on the appropriate Firefox tree on Tinderbox. I also want to experiment with different notification systems.


Firebug 1.4.1 and Some Activation Tips

The Firebug team released version 1.4.1 this week with a bunch of fixes large and small. Hans Hillen added a bunch of fixes for the a11y features, including improved Mac styling, some performance improvements and fixes to the CSS panel. John added a bunch of fixes around the activation mechanism, including a visual glitch that made it look like Firebug was turning off and then on again when a page was reloaded. He also added some additional fixes around JS debugging. Honza released a work-around for a problem where onreadystatechange events were getting lost during AJAX calls in certain situations. (Thanks to Nicholas Zakas for pointing that bug out to us and helping us test it!)

I think the biggest change to Firebug from version 1.3 and earlier is the new activation mechanism and it’s something that can take a bit of getting used to. It’s definitely something we could have blogged more about during the coming months and it still causes some users pain. Honza wrote an excellent introduction to it, which I’ve mentioned here before.

One trick that has stymied some users is how to see an initial request (GET) from an HTTP server if Firebug isn’t active. Or how do you follow Net traffic from one domain to another when you click on a link?

The secret is on the Firebug status icon’s context menu and it’s labelled “On For All Web Pages”.

Firebug's Context Menu

Selecting this option will open Firebug for any page you visit, giving you a seamless view of your network traffic. Deselecting that option will allow you to turn it off again.

The complementary function, “Off for All Web Pages” will also do a little more than just turn off Firebug. It removes the list of active webpages Firebug has registered, essentially clearing the scene. If you’ve ever visited a webpage and wondered why Firebug was active on it, it’s because you turned it on there before, then probably closed that tab with Firebug still open. Subsequent visits to that or any other webpage you had Firebug opened on (and didn’t turn off!) will reopen Firebug. Selecting “Off For All Web Pages” will clear that list so you don’t have any more surprises.

Don’t forget to turn off “Off For All Web Pages” when you want to use Firebug again. Opening it and pressing reload may confuse you.

(thanks to “brahmana” from IRC for reminding me to write this post)

Lastly, my standard plea: please report any bugs you find on the project’s issues page.


Copy Bookmarklet

I found a cool little feature this morning while poking around in Firebug’s command line code. If you expand the Console’s command line to the large area (using the little up arrow on the right of the command line), you can enter a block of text, nicely formatted. This is probably not news to anyone. Though if you click the little “Copy” button at the bottom of the large command line panel, it trims out the newlines and prepends “javascript: ” on the front of the line, producing text that looks like this:

javascript:var s = document.getSelection(); if (s) { window.open(s); } else { alert(“No selection”); } void(0);

From this:

copy bookmarklet

(Firefox adds %20 for each of the spaces when you save it as a bookmarklet)

The above snippet grabs the currently selected text in a web-page and opens it in a new window. Add it to a bookmarklet of your own on your toolbar and you have a convenient way to open new text in a separate tab. For bonus points, install the keyconfig extension to create a keyboard shortcut (you’ll need to force-install the extension and write a little function to get that to work). Thanks to Neil Lee for the keyconfig tip!


The Road to Firebug 1.4

It’s been a long haul but Firebug 1.4.0 is finally out the door.

Honza wrote a good introduction to the new activation model awhile back and you may find it useful to understand the differences between activation mechanisms in 1.3 and 1.4.

JJB writes: “Firebug 1.4 is a true community achievement. We have had contributions from many developers and a few designers, with additions both large and small.”

And it’s true. We’ve seen contributions from several new people over the past year and some long-standing issues fixed. Kevin Decker, creator of the nascent FireDiff extension for Firebug contributed a new multi-file search capability. Hans Hillen working with the Paciello Group has done a tremendous job of making the Firebug UI accessible to screen readers. He also added a new Customize (keyboard) Shortcuts preferences pane (available from the Firebug menu).

You should also see some new icons in the Windows version of Firebug. Austin Andrews (aka Templarian) in IRC modified some of the Silk icons from FamFamFam for inclusion in Firebug. Some improved debugger icons have made it into the Mac and Linux versions as well. We still need to do some tweaking of the Mac skin so, if you or anyone you know would like to help out, get in touch with us.

oh, and that “Off” label on the right of the panel is a temporary thing to introduce people upgrading from 1.3 to the new behavior of the panel control icons (minimize, detach and close/off).

Over the next week or so we’re going to be writing more about the new features in Firebug 1.4 and how to use them.

Hats off to the Firebug developers and to all the great testers and users who helped us through the alpha and beta stages. We couldn’t have done it without you.

photo by Mike McCaffrey via Flickr. Thanks!


How do you surf the firehose?

fire hoseA colleague asked me how I stay on top of the constant surge of information produced by Mozilla and Firebug and whatever else I follow. The question was a good one in and of itself and I replied with my little list of things I read and said I might blog it, because it could be helpful. His reply suggested a Seven-things-style meme to find out what other people are reading and how they stay on top. At the risk of having the entire internet hate me, I conceded that this was an excellent idea.

First, a disclaimer: I don’t believe any one person can possibly stay on top of the incredible volume of information and noise produced in and around Mozilla. Especially when you start doing transitive closures on the information and pulling in data about Mozilla and ancillary projects. I am not claiming this is definitive or even remotely efficient. It sort of works for me, and it’s settled into enough of a routine that I can stick with it.

So, without further ado, the meme-ified questionnaire:

Q1: What is your reading schedule? Do you have a schedule?
I have a schedule, but I also read randomly when I’m stuck someplace with my phone and have decent wireless connectivity. I typically start the day with email and bugmail, then check important feeds. Twice per week (usually), I check digestified versions of dev.planning and platform. Usually Monday and Wednesday. I don’t have it scheduled, (though maybe I should!) but I read feeds throughout the day. I will admit that they can be a strongly seductive distraction from real work. And of course, there’s IRC competing for my attention.

Q2: What do you read daily and how often?
E-mail, naturally. Several times / day, first pass, check for urgent messages, scan subscribed lists and subfolders later.
Blogs / Planet (with coffee)
Bugmail. Check once morning, once afternoon.
Firebug Bugmail. As it comes in.
Firebug working group individual emails

Q3: What do you read more than once / week? How often?
newsgroups, dev.planning, dev.platform
Blogs, Newsfeeds

Q4: What blogs/feeds/newsgroups do you read? (list three or more)

blogs:
lifehacker
daring fireball
schneier on security
michael geist
planet.mozilla.org – this I have been reading less of late, mostly because of the noise. Highlights from About:Mozilla newsletter fill in the important gaps.

feeds:
cbc/bbc
macnn
engadget

newsgroups:
firebug discussion group
mozilla.dev.planning
mozilla.dev.platform
mozilla.dev.extensions

Q5: Lastly, name a guilty pleasure in your feedreader:
kotaku!

bonus question: What do you use to read feeds?
I use Feedly. I used to use Vienna, but found the app was stagnating somewhat. I have also tried Times, which came with this year’s MacHeist bundle and it looks good, but prefer Feedly’s integration with Firefox. I considered trying Fever which looks promising.

Now tag at least three people you want to hear from (making sure you notify them via email, twitter, or whatever means of communication you have in case they don’t actually read your blog all the time):

Deb Richardson
Mike Beltzner
Kev Needham
Curtis Bartley

Let the meming begin!


Velocity 09

grainy steveLast week Honza and I went to San Jose, CA for Velocity 09 to hang out and take in some of the excellent presentations taking place there.

I can say without hyperbole that this was the best conference I’ve attended. The presentations were from people doing real large-scale web development and included a fair amount of real data and some of their solutions to hard problems.

One of the highlights was John Adams of Twitter talking about the engineering challenges they’ve encountered keeping your tweets flowing. They’ve rewritten intensive chunks of code in C. They’ve implemented their own queue system (called Kestrel which has an API very similar to memcached). They use Google Analytics to monitor the frequency of the Fail Whale. You can see the whole presentation here, on video.

Other speakers I enjoyed seeing included Marissa Mayer of Google, Nicholas Zakas of Yahoo on JavaScript performance tuning and the mighty Steve Souders (pictured above) talking about Even Faster Websites. I liked his presentation so much, I bought the book!

Some of the take-aways from the conference were: Instrument Everything. Analyze your performance constantly. Employ phased roll-outs and measure user reactions to changes.

I was surprised to learn that changes in website responsiveness sometimes as little as 50ms could incur changes to pageviews or searches, directly impacting revenue. Anyone whose ever played Rockband or, gosh, a real guitar or set of drums can tell you that 50ms is very noticeable and at the outer-limit of responsiveness (not to mention can make your music sound imprecise). Humans are capable of detecting latency well below that number, but the surprising thing is that we humans are now expecting this level of performance from our websites.

You can see a simple visual demonstration of this with Ben Galbraiths’ feedback demo, presented by Ben and Dion Almaer in their On Responsiveness session.

I don’t think it’s something we would consciously think about when using a site, though it would likely form some sort of nebulous impression upon us. Using a search engine that didn’t post any response for 50ms or worse would probably make us think, “this thing’s slow” or “I’m not getting any results”. Those delays add up over time. As users know there’s going to be a delay, they might start a search and flip to another application or browser tab. As soon as that happens, the user’s attention is lost and may not return.

What I find really interesting about this, is that people are now treating websites with the same levels of performance expectations that they have with video games and desktop applications. Website performance is more important than ever, so if you’re creating or maintaining a website, keep that in mind.

Too much content, not enough blog. I’ll try to talk about some of the other cool things I saw later this week.


Firebug 1.4.0b1 Limited Release on AMO

Today we’ve pushed Firebug 1.4.0b1 (same as 1.4.0a31) to addons.mozilla.org. Currently, we’ve only turned it on for users of 3.5b4 and later, but this version is fully-compatible with Firefox 3.0 as well. Users of Firefox 3.0 who want to try out Firebug 1.4 should download it from getfirebug.com/releases/firebug/1.4 or disable version checking on AMO. When we ship the final version of Firebug 1.4.0 we will set the compatibility for all users of Firefox 3.0 and 3.5.

This is a little different from previous releases. For versions 1.2 and 1.3, we released betas on getfirebug.com and ask users to download from there. We’re adding the betas to AMO this time to allow individuals using Firebug on Firefox 3.0 upgrading to 3.5 to have a seamless upgrade experience. Also, the reason we didn’t enable this for users of Firefox 3.0 is that we feel this is still Beta-level software and didn’t want to throw them into that ring without fair warning first.

What’s new in this release? Quite a lot, actually:

We’ve still got a fair bit of work to do to wrap this up. Templarian’s icon updates are still in the pipe as well as documentation updates and ongoing bugfixes, so stay tuned for more.

To everybody who’s contributed to this release, I would like to extend huge thanks for your help and hard work! Everybody who has tested, reported bugs and joined in on test-day, we couldn’t have gotten here without you.

As always, please report any bugs to http://code.google.com/p/fbug/issues. This software is beta!


← Before After →