When Apple migrated the Mac operating system platform to Mac OS X, one of the key components was an underpinning based on the FreeBSD operating system. The use of an open source operating system as the core has in turn led to an increase in the use and availability of free and open source software (FOSS). It is now much easier to develop software for the OS X platform (development software is included, instead of being an expensive addition) and this makes it both easier for people to get involved and more likely to take part in open source community projects.

Despite the ease, there are still some areas of software development where the complexities of the application are too great. Web browsers are a classic example of this—although the principles of web browsing are quite simple, making all of the components of a typical web page (JavaScript, different image formats, plug-ins, CSS etc.) work effectively is quite difficult. Hence the need for community-based projects where many people can pool their experience.

As a knock on effect, web browsing in the free software space is now based around two main camps, those based on the Mozilla codebase (Camino, Firefox, Mozilla) and those based on the KDE sourced KHTML rendering engine (Safari and OmniWeb). Projects based on the former are completely free software, with both the rendering engine and interface being a free software project. The latter are not strictly free software, but the core rendering engine on which they rely is. It is only the interface which is not free software.

For the review, I’m going to be taking a closer look at the features and functionality of the three free software browsers—Mozilla, Firefox and Camino, and what differentiates the functionality of these three browsers from each other. I’ll primarily be comparing speed and functionality, but I’ll also use the opportunity to cover some of the issues that affect the browsers on individual sites. I’ll then take a very brief look at the quasi-free software browsers; Safari and OmniWeb.

Web browsing in the free software space is now based around two main camps, those based on the Mozilla codebase (Camino, Firefox, Mozilla) and those based on the KDE sourced KHTML rendering engine (Safari and OmniWeb)

Mozilla Suite

The Mozilla project was borne out of the Netscape Navigator project; Mozilla being a combination of the term Mosaic killer (which is what they hoped Netscape would be) and a reference to Godzilla. Mozilla was also the name of the Netscape mascot—appropriately enough usually represented by a humanoid-lizard, like Godzilla. The Mozilla Organization was created in 1998 to create the next generation of Netscape and was registered as a not-for-profit organization (the Mozilla Foundation) in 2003. Today, Mozilla is the name used to refer to the range of browsers produced by the Mozilla group, notably the main Mozilla Suite and the forks of Firefox and Camino.

The Mozilla Suite is the name given to the software package that incorporates the functionality of a browser, email, newsgroup reader and HTML editor. The core of the Mozilla suite is the Gecko rendering engine which is also shared by Firefox and Camino. The Gecko engine is based on the HTML/XHTML, DHTML and other standards that make up the web environment and is specifically designed to render these in a consistent fashion across platforms. This means that you browse a page on Mac OS X and Windows within a Mozilla browser and get a consistent view. It also means that, in theory, different browsers that use the engine will have a consistent view. This isn’t quite the case for reasons that will become clearer as I look at the other browsers from the Mozilla stable.

For example, let’s look at the homepage for MCslp.com, my website, which is based on the WordPress blogging engine with a theme which is XHTML compliant. You can see how this looks in Figure 1.

MCslp.com in Mozilla

As the larger “internet suite”, the Mozilla browser is more geared toward users who want a consistent interface and environment for all of the browsing and internet needs. The interface, as shown in the figure, is based around the original Netscape browser. Shown is the Classic theme but a standard installation also includes the Modern theme which is a little more aesthetically pleasing. This retains the “toolbar” style of the original—including “handles” for moving the different toolbars around and changing their order and layout. You can also click on these tabs to “collapse” the tool bar so that it takes up less space. What you don’t get in the standard format is a convenient search bar for Google or other sources; instead you get a button that takes you to a predetermined Search button and the location field doubles up as the source for search criteria. What you cannot do is customize the toolbar you can enable and disable buttons, but not actually modify or add to the suite of buttons.

Like Firefox, Mozilla supports both themes—which change the appearance of buttons and other aspects of the interface—and extensions, which provide additional functionality. For example there are extensions that provide Ad filtering, download management or additional information during browsing. For example, the LiveHTTPHeaders extensions can display the header information sent during an HTTP transaction—invaluable during development. Unlike Firefox there is no convenient extensions manager, and in fact Mozilla almost hides the existence of extension support from the application.

In terms of simple internet browsing Mozilla is more than capable. It does sometimes feel slower than the alternatives and there is often a discernable pause just before the page is displayed that can become a little frustrating. For simple text sites it isn’t a problem, but those with heavy graphics, or complex tabular pages do demonstrate the problem.

In terms of the quality of the display and parsing, I experience very few problems with Mozillawhen laying out different pages and sites. The only times you experience any specific difficulty is either when the site is not standards compliant, in which case some interesting “default” choices are made about how to layout components, or where the site has deliberately used Internet Explorer capabilities to provide functionality. For example, some menus and items that rely on JavaScript or ActiveX simply don’t work. I’ve also experienced some occasional issues when logging into sites through a simple password system. For example, my blog at Computerworld never loads properly after login. Again, I suspect this is more of an issue of the site code, rather than Mozilla, but it can be a frustrating experience.

Like Firefox, Mozilla supports both themes—which change the appearance of buttons and other aspects of the interface—and extensions, which provide additional functionality

Being a suite of internet applications, rather than just a bare browser, Mozilla has the benefit of including most of the tools you will need. I also love the way that you can read/reply to email directly from within Mozilla. This comes in particularly handy if you are frequently using sites that use email links; there is none of the delay sometimes experience while the OS works out what to do with the link. The embedded IRC client is also very handy. However, once you start using all of the components at the same time, you can sometimes experience some performance problems. Also, as a single monolithic application the memory usage can be prohibitive. Although memory management in OS X is efficient enough that you don’t often experience problems, the memory issue is almost certainly related to some of the performance issues I experienced, especially while monitoring the load and memory usage of Mozilla while browsing various pages with all of the options enabled.

I liked Mozilla, but I have to admit to preferring other applications for my Email and chat requirements, and this is where Mozilla, as the “do all” application, starts to look like overkill if all you want to do is use the browser. A good example here of the limitations of the built in system is the address book. Within Mozilla you have your own special address book section, but this doesn’t integrate with the OS X address book and that means you can’t share instant messaging details with iChat and there is no provision for SMS messaging, an option built into the standard OS X Address Book application.

Where Mozilla is most likely to be used is within an organization where they want to standardize on a single platform for browsing and email access, and are probably supporting an LDAP server for address book functionality. In fact, I deployed Netscape Communicator, which provides similar functionality, in this way several years ago.