Blog
August 12th, 2008
Firebug 1.2 final is set to be released sometime within the next week or two which means that our goals for Firebug 1.3 need to be pretty clear at this point. Last week the Firebug Working Group convened at Google to discuss the goals for the upcoming release. In taking a step back and looking at what was most important one thing was quite obvious: The stability and performance of Firebug needs to be improved.
Unfortunately we're in a very difficult situation. There are, approximately, three developers who've done any sort of serious bug fixing on the internals of Firebug. One is John J. Barton (of IBM - primarily responsible for the 1.1 and 1.2 release of Firebug) and the other is Jan Odvarko (of Mozilla - part of the new Firebug team). Unfortunately the primary source of information lies in Joe Hewitt (the original creator of Firebug), who is quite incommunicado these days.
There are a few areas in which we (and, specifically, the Mozilla Firebug team) need to work in order to gain a solid footing.
Improve the knowledge of Firebug that we have.
Right now information about Firebug internals are quite limited. Not only does there need to be some serious overviews of what's there but inline documentation needs to be improved as well. It can be incredibly hard to hack your way around some aspects of the code base, especially when it isn't obvious how something works.
We're going to be working two-fold in this area: To start Rob Campbell and I will be working on some Firebug extensions in order to get a better feel for the code base - and secondly we will, as we go, write up tutorials and documentation for what we find.
Jan has already written up an excellent series of tutorials that explain how to construct Firebug extensions. They're, already, quite valuable.
Build a runnable set of test cases to prevent regressions.
The unit testing (or, really, any testing) situation in Firebug is quite abysmal. Features have gotten accidentally removed from releases simply because they weren't immediately apparent that they existed. We need to make sure of two things: 1) That existing features don't break or get accidentally removed and 2) That a good enough coverage of the internals is in place to support future development.
Since there is a considerable amount of traffic through the code base (developers contributing patches, multiple developers handling different modules - all over some 35,000 lines of JavaScript code) some form of diligence needs to be provided in order to prevent errors from slipping through.
Track the state of Firebug performance.
There's, effectively, no picture of how Firebug is currently performing (or, more accurately, hindering performance) in Firefox. If we want to improve the quality of the code we have to have a clear picture of which areas are problematic. This is one area in which Mozilla's resources can be especially beneficial.
In Mozilla there is a system called Talos which is used to create builds of Firefox (for all the various branches - right now we're testing Firefox 2, Firefox 3, and Firefox 3.1) and run them against sets of performance tests. The tests consist of page rendering performance, CPU usage tracking, memory usage tracking, JavaScript performance, browser start-up time, graphics rendering, and on and on.
A sample chart - showing page loading performance on Windows XP (a ton more can be found here):
We want to create some builds of Firefox that have Firebug on in various states. For example: Firebug installed (but disabled), Firebug enabled, Firebug with console enabled, Firebug with debugger enabled, Firebug with network monitoring enabled, etc. With all these permutations we'll be able to get an exact number for how much overhead current Firebug code is providing and where we can start to make necessary improvements.
Audit and Improve.
Finally, once we have some documentation about the structure, a test suite running, and nightly performance numbers being generated we can really start to dig in and make improvements. It's going to be slow-going at first but laying this groundwork will make for an effective use of our time (increasing the likelihood that other people will be able to help contribute to the codebase, as well). If we can have a stable and fast Firebug 1.3 ready in time for Firefox 3.1 (which is due out this fall/winter) then I feel like we will have made some good headway and started to serve our purpose well.
Tags: firebug, mozilla
14 Comments on 'Tracking Firebug Performance'
July 17th, 2008
I've got a mini-announcement. Starting this week about half of my time at Mozilla is going to be spent driving the direction of the brand-new Mozilla Firebug team. I'm, understandably, quite excited about this proposition. Like all web developers I've found Firebug to be an invaluable tool for web development.
We have a great team forming - I'm going to be joined by:
We're in a very primordial stage right now - we're meeting at the Firefox Summit at the end of the month and again at the beginning of August for the Firebug Working Group. We'll be setting some major goals for post-Firebug 1.2 development. I highly suspect that we'll be doing some exploratory Firebug extension development as well.
In the meantime we'll be hanging out in the Firebug IRC channel, which can be found here:
Server: irc.mozilla.org
Room: #firebug
We're going to love to hear any suggestions for feature development - I'm sure you've got tons of ideas - and we do as well. I'm quite excited about all of this. Here's to a bright Firebug future!
Tags: firebug, firefox, mozilla
75 Comments on 'Firebuggin''
July 10th, 2008
This week I've been busy working on implementing a test suite for the Selectors API specification. I picked up a new microphone recently so I decided to do a quick walkthrough of the work that I've been doing and how I've been going about it. You can view the the video below:
Implementing a Selectors API Test Suite
You can run the test suite for yourself here (it's still very much in flux - there are various parts that may still be wrong):
http://ejohn.org/apps/selectortest/
Here's a quick break down of a test run that was done earlier:
- Special Firefox 3.1 Build (73.8% - More details)
- Safari 3.1 (49.3% - No Fragment or Namespace support)
- WebKit Nightly (51% - No Fragment or Namespace support)
- Opera Gogi - "ACID3 Build" (76.7% - No Fragment support)
- IE 8 (Can't run - the file is proper XHTML so it tries to download it.)
- Firefox 3, Opera 9.5, IE 7 (0%)
The work that is being done to implement the specification in Firefox can be seen on its associated Bugzilla bug. I'm shooting very hard to make sure that everything is in place so that this makes it in to the upcoming Firefox 3.1 release (the first alpha of which is due out in a couple weeks). The benefits that this will have for both JavaScript libraries and their users will be tremendous.
Tags: css, firefox, mozilla, w3c
16 Comments on 'Implementing a Selectors API Test Suite'
July 2nd, 2008
Last week it came out that, in Firefox (and other Gecko-based browsers) you could dip into the private scope of a function using eval, like so:
// Getting "private" variables
var obj =
(function() {
var a =
21;
return {
// public function must reference 'a'
fn:
function() {a;
}
};
})();
var foo;
eval('foo=a', obj.fn);
console.log(foo); // 21
I think the common response to seeing the above was something like: WUH!?!?
As can be seen in the ensuing discussions.
Perhaps more interestingly is the dig in to try and figure out how on earth this feature made it in to the language to being with. Brendan Eich provides some insight:
3.2 <fur> 1998-04-23 17:30: Initial checkin of JavaScript 1.3, migrated from JSFUN13_BRANCH in /m/ src repository
This eval extension, if memory serves (I was in mozilla.org at the time, not in the JS group at Netscape) originated in conversations with Microsoft's rep during ECMA-262 standardization, trying to reach agreement on a way to eval in other scopes.
At this point, however, it's pretty safe to say that since so few people know about it, and that (hopefully) there are no important sites relying upon its behavior, it can be stricken from the record.
Which it has been.
It's been a crazy ride but you can expect to see this feature gone in Firefox 3.1 (the next release of Firefox, set to debut this year).
Tags: firefox, mozilla, javascript, links
19 Comments on 'eval() Kerfuffle'
June 25th, 2008
Visit: New CSS Features in Firefox 3
David Baron, a Mozilla developer, has a write-up on the new CSS features that are available in Firefox 3. There's a mix of additions - everything from CSS 2.0 and 2.1 features to new additions that are tracking CSS 3.
Some of my favorite additions include:
The CSS 3 Box Specification (in the form of -moz-max-content, -moz-min-content, -moz-fit-content, and -moz-available values to width, min-width, and max-width).
-moz-fit-content actually does let authors do some things that previously weren't possible without tables, such as putting a background on headings that doesn't fill the whole width of the container unless the heading does, but is a single rectangle if the heading breaks to multiple lines (see Demo).
Wrapped whitespace (white-space: pre-wrap). This allows you to have a <pre/> whose contents are wrapped nicely, while still maintaining its rigid structure.
rgba() values. You can now apply opacity directly to background colors (as opposed to having to create a shim div/span and styling that instead). Note that the below text is fully opaque.
body { background: url(stripes-6); }
div { background: rgba(0, 255, 0, 0.5); }
h2 { background: rgba(255, 0, 0, 0.5); }
inline-block and inline-table Such a powerful addition - and one that now brings Firefox in line with most other browsers. It'll allow you to create much-more-complicated layouts that were previously very trying to implement using normal CSS. Demo.
Tags: firefox, mozilla, css, links
13 Comments on 'New CSS in Firefox 3'
June 23rd, 2008
It was fascinating to watch the unveiling of Firefox 3 last week. I'm pleased that, in some small way, my contributions helped to bring this browser out the door.
First 24 hours: 8.3 million downloads, 69 downloads/second, 20 Gb/s Peak Transfer
While I generally focus on issues tangential to JavaScript code, at Mozilla - like testing, performance analysis, specifications, standards, bug hunting, speaking, demos, and blogging - some of my code is live within the browser, and that makes me quite happy.
One of my first tasks at Mozilla was to, with Mark Finkle, develop a JavaScript API for performing common interactions typically desired by extension developers, called: FUEL. This is a pure-JavaScript implementation that sits as a proxy inbetween the developer and the various, traditional, XPCOM-style ways of performing actions.
If you're interested in learning more about FUEL I've collected a number of links and examples:
The Development of FUEL
FUEL was created over the course of a couple months, in early 2007, by Mark Finkle and I. Mark had much-better knowledge of Mozilla's APIs and I had good knowledge of JavaScript and API design - the match worked out nicely. I've written a couple blog posts on FUEL and so has Mark.
You can also see the features and code that went into FUEL 0.1 and FUEL 0.2 in Bugzilla.
FUEL, Today
Today FUEL lives in Firefox 3 (meaning that you can use it to develop Firefox extensions) and is part of the core Mozilla platform (meaning that portions of the API will be available in any Mozilla-based application that is built). For example you can even use a FUEL-like API in Thunderbird (called 'STEEL'). Here are some of the best resources for getting started with FUEL in Firefox 3:
Here are some of my favorite example of FUEL in action. It was very important to me that the most-common actions take no more than a single line of code to perform - with even complex actions keeping nice and trim.
Open, and activate, a new tab pointing to Google.com
Application.browser.open("http://google.com/").active = true;
Close the active browser tab
Application.browser.activeTab.close();
Close all tabs that mention Google
Application.browser.tabs.forEach(function(tab){
if ( tab.url.match(/google/) )
tab.remove();
});
Add a new bookmark pointing to Mozilla
Application.bookmarks.add("Mozilla", "http://mozilla.org/");
Remove all bookmarks pointing to Google.com
Application.bookmarks.all.forEach(function(cur){
if ( cur.url.match(/google.com/) )
cur.remove();
});
FUEL, Future
Development is still going strong on FUEL. There's a Google Summer of Code student working on extending the API and porting it to more parts of the platform (along with backwards support for Firefox 2!). We'll probably end up seeing this in Firefox 3.1 (the next version of Firefox, due out later this year).
If you have any questions concerning how to use FUEL, or to develop Firefox extensions in general, your best bet would probably be to join the #extdev IRC channel on irc.mozilla.org. Lots of knowledgeable people hang out there and will be more-than-capable of answering any questions that you might have.
Once again, I'm terribly excited by the final release of Firefox 3 - here's hoping to many more excellent releases to come!
Tags: extensions, firefox, mozilla, javascript
12 Comments on 'Simple Extensions in Firefox 3'
May 20th, 2008
There's been an interesting security adjustment in Firefox 3 that'll have some, potential, ramifications in some (file://-hosted) web pages. Specifically how local files are referenced and accessed, in parent directories, has changed.
For example, previously you could create an HTML page and have it request a file in a parent directory, like so:
<html>
<head>
<title>Local File
</title>
<script>
var xhr = new XMLHttpRequest();
xhr.open("GET", "../some/file.txt", true);
// ... handle the response ...
xhr.send(null);
</script>
</head>
<body></body>
</html>
However that is no longer possible (just to emphasize: This is no longer possible only on locally downloaded web pages, running in file://...) as an HTML page can no longer access files in parent directories. This includes both ../ relative URLs and file://... absolute URLs.
There's a detailed discussion in the bug ticket concerning this change. Primarily it boils down to the fact that:
Users frequently download HTML pages for a variety of reasons, HTML pages have full access to the hard drive and the ability to do cross-domain communication, this combination leads to an unsuspecting mess where malicious pages can actively try to steal user information.
This change is two-fold: It's possibly frustrating (there's bound to be some HTML page somewhere that uses XMLHttpRequest to local in local information, located above the current directory) and unavoidable (having this security concern left in place would lead to undesired situations, if they haven't already).
Generally speaking I don't think this change will affect many people - but it's just something that you should be aware of, when planning your sites for Firefox 3.
UPDATE: In the original post I interpreted the Bugzilla bug as being that ALL attempts to access parent-directory files were blocked when, in fact, only items bound by the same-origin policy are (like XMLHttpRequest). This should affect significantly few pages but it's good to be aware of.
Tags: javascript, firefox, mozilla, html, security
23 Comments on 'Tightened Local File Security'
April 29th, 2008
Deb Richardson wrote up an interesting piece today describing color profile support in Firefox 3. The result of a color profile is a more-accurate mapping from an original set of colors to better match the intended rendering. Profiles can be provided by the operating system (to provide better color distribution globally) or even locally by individual images.
For example, observe the following image which compares the difference between Firefox 2, Firefox 3 (with color profile support), and an image in Adobe Photoshop:
There is a noticeable difference between the rendering of the image in Firefox 2 compared to both Photoshop and Firefox 3 (in which they are rendered identically). All of this is due to the fact that Firefox 3 and Photoshop use the additional color profile information to get a better mapping of the resulting colors.
There's one tricky point, however: Color profile support is disabled, by default, in Firefox 3. However, it can be quickly enabled by installing the Color Management Add-on or by twiddling some options in about:config.
The reasoning for the feature being disabled was outlined for two particular issues:
- There was a large 10-15% drop in performance when this feature was enabled. The extra time spent on large images began to add up quite quickly. Obviously this will be a point that'll be worked on in upcoming releases - but introducing a regression that large was pretty much unacceptable.
- Plugins (such as Flash, Silverlight, Quicktime, etc.) did not do color profile correction, causing rough mis-renderings to occur. This correction is, unfortunately, left up to the plugins themselves - leaving this out of the realm of the browser itself. It's unclear as to how this will be resolved.
At the very least, however, you can grab the Color Management Add-on with your copy of Firefox 3 and begin to view your pictures with an extra level of color and crispness.
Tags: firefox, colors, mozilla, browser
20 Comments on 'Color Profiles in Firefox 3'
Next entries » ·
« Previous entries
