The Inside Track on Firefox Development.

« March 2005 | Main | June 2005 »

May 19, 2005

Netscape 8 Is Unsafe

Users of the Netscape 8 browser can click here to verify that their browser exhibits the Cross Site Scripting flaw that was fixed for Firefox 1.0.4.

If security is important to you, this demonstration should show that browsers that are redistributions of the official Mozilla releases are never going to give you security updates as quickly as Mozilla will itself for its supported products.

Posted by ben at 11:06 AM | Comments (75)

May 13, 2005

1.0.4

Chase Phillips has now got spitting out security updates down to an art. We love you Chase. We also love Johnny Stenback, Vlad, Dan Veditz, Boris, and David Baron for getting the security patches put together and verifying them so quickly. Thanks also to Paul and Jesse for helping to identify the problem.

Posted by ben at 3:04 PM | Comments (3)

Some More on Perfection

I realize the brevity with which I justified my "cutting corners" statement in my previous entry would lead some people to freak out. Let me recap:

The Mozilla team takes security, dataloss and topcrash bugs very seriously.

To ship software on time (where on time equals this month, this year, this decade), a set of bugs (usually features, or bugs that are harder to reproduce) fall off the boat. This is hard. Some of the bugs you may personally care a lot for and really want to fix. The original Firefox 1.0 plan called for a comprehensive rework of the somewhat crusty Bookmarks manager, but in the end we decided shipping in 2004 was more important, and we should save ourselves something for 2.0.

I understand this conflicts with some folks' dogma, but this is the way product releases work. This is OSS, but it's OSS that we intend to have high impact, so sitting around for years polishing trying to reach some kind of unattainable "perfection" (see last post) serves no one.

Posted by ben at 11:24 AM | Comments (26)

May 12, 2005

Safari, KHTML, Perfection

I was reading CNet's coverage of some of the Safari vs. KHTML discussion that's been going on lately and was struck by a comment made by one of the KHTML developers...

"In open source, everything's supposed to be done the right way, but sometimes the less correct way is faster," Rusin said. "In fixing one problem, they were breaking a whole bunch of other things. Apple developers were focused on fixing bugs in such a way that we could not merge them back into KHTML. Those fixes were never an option for us."

Certainly, every project is free to be run the way it wants to be run - but there are a couple of givens here if you're trying to make software that changes the world:

No software is ever perfect.
In order to have the most positive impact, you need to take advantage of opportunity especially when it comes to release time. This means you may have to cut corners in some areas in order to ship on time. Smart money cuts corners in areas that people are less likely to be concerned about.
There needs to be a strong focus on meeting the needs of the target audience.

Some people would call me careless, but certainly I've been bitten by my own carelessness in my past enough to have that trait be tempered by some caution. Given (1) above, I certainly believe it better to iterate quickly even if you make some mistakes - get your vision out there for people to test and give feedback on rather than fussing for months before releasing anything, only to discover it was completely off track.

Not everyone wants to change the world, but Apple does - and although they may have done the least required of them in accordance with the licenses of the original source code, it was within their rights to do what they did, and no one should begrudge them for it. Safari's renderer is vastly superior to the KHTML used by Konqueror. Should I have to wait months or years for every patch that makes Safari more compatible to be done perfectly? No. Well, maybe as a software engineer I should. But does anyone that isn't a software engineer care? Probably not. Case closed.

Posted by ben at 12:23 PM | Comments (39)

May 7, 2005

Help us with Tiger integration!

We're always looking for ways to improve our support for the different platforms that we run on. We're all very excited about some of the new capabilities exposed by MacOS X Tiger, but most of the core development team is swamped with 1.1 bug tracking, feature work and security bugs and so I'm asking for help.

For starters, it'd be good to have some actions for Automator (at least a set that offers compatibility with what Safari supplies, and maybe a few other things), and support for Spotlight. If you're interested, join the discussion in bug 293322 (Automator) and bug 293323 (Spotlight) - we need functional specifications (a list of preliminary actions, supported data types etc), UI drafts where appropriate (for Automator Action configuration). This should be intensely interesting work for anyone who loves MacOS X development and Firefox.

Posted by ben at 9:52 PM | Comments (18)

May 2, 2005

Update System

One of the biggest difficulties that the Mozilla Foundation has encountered in the months following the Firefox 1.0 release has been managing the Software Update System for distributing updates to 1.0 users. We had never done anything of this scale before, and the system in place is representative of approximately a week worth of work on my part prior to 1.0 with little understanding of the problems that the Mozilla release team would end up facing.

In this light, improving the Software Update System has become a primary objective for Firefox 1.1. We have already met several times, and there are groups now working on the various pieces of the system. Darin Fisher and I will be working on the client side segments, with help and input from Benjamin Smedberg, Doug Turner, Daniel Veditz, Chase Phillips, Chris Beard et al. I have developed some initial UI mocks which you can find on the Mozilla Wiki in the Software Update section, along with some growing but rough design documentation for the client side piece. Darin has figured out how to get binary patching working, and is working on a system for incremental background update download. I will post updates about the client side pieces as they develop further.

Posted by ben at 1:01 PM | Comments (3)

Changes for Extension Developers

Last week I landed some important changes to the Firefox Extension management system. These changes involved almost a complete restructuring of the Extension system and offer the following benefits (briefly):

For developers: You can now have Extensions that live outside the profile and application Extensions directories. This may make development easier, because you can have your Extension source code live somewhere else, use the flat chrome packaging (instead of .jars) and place a file in the profile "extensions" folder whose name is the {GUID} of your extension that contains a path to the location of the Extension.
For users: You can install extensions by dropping their XPI into the profile or application Extensions directory.
For developers: You can install extensions by expanding the XPI into a folder whose name is the {GUID} of the extension, and drop it into the profile or application Extensions directory.
For developers: Before 1.1 (not yet, but soon) you will be able to install extensions by setting a registry key.
For users and developers: You will be able to uninstall an Extension by simply deleting its folder from the profile or application Extensions directory, or removing the text link file.
For developers: XULRunner applications will be able to specify their own special kinds of Extension install locations in addition to the profile and application directories, e.g. a special kind of registry key mapping, etc.
For developers: More comprehensive logging of installation and updating.
For users: Move Up/Move Down should now work properly.

The new architecture for tracking how Extensions are installed is much improved over the one used by Firefox 1.0 and will allow us to do many new and interesting things, make our build and release processes more efficient, make application install easier, and allow for other types of items to be more easily tracked by the Extension system.

I want to dish out thanks to Benjamin Smedberg and Darin Fisher for the excellent and prompt feedback on a 5600-lines-added-or-changed patch and helping get this checked in as quickly as possible for the Deer Park Alpha.

Posted by ben at 12:52 PM | Comments (6)

©1997-2006 Ben Goodger. All Rights Reserved.
Opinions expressed here are my own, and not those of any organization that I may be affiliated with.
Reload icon is © Stephen Horlander;
Firefox logo is by Jon Hicks, and is a trademark of The Mozilla Foundation.
GetFirefox buttons are from rakaz