Gecko 1.9.1 Mac OS X Plans

We’ve started working on Gecko 1.9.1 for Mac OS X. It is early in the development cycle and things could change, but I want to give people an idea of what we’re planning on doing as of now.

Aside from the usual bug squashing, we’re going to focus on minimizing Carbon usage and getting ready for 64-bit. Gecko 1.9.0 is generally Cocoa-based but it still contains a modest amount of Carbon and other code that is not 64-bit-ready. We’re probably not going to be Carbon-free or 64-bit-ready for the Gecko 1.9.1 release, but we can make a lot of progress.

  • I’m adding support for NPAPI plugin event model negotiation and the Cocoa event model in bug 435041. This will allow for Carbon-free plugins and is major step towards 64-bit Gecko on Mac OS X.
  • I’m working on new file system interaction code for Mac OS X in bug 438694. The goal of this work is modern and clean 64-bit-ready code that uses supported APIs.
  • I’m also hoping to rewrite our print dialog implementation in Cocoa. It is one of the few components that are still completely Carbon-based.

We’ll also be doing some long-overdue general cleanup and performance work.

  • I have rewritten much of our native menu code in bug 433952. We’re doing this to improve code size, code clarity and run-time speed. The new implementation is completely decomtaminated, ~700 lines of code lighter, better organized and much easier to understand. In the future we will be able to make changes and fix bugs much faster. It will also be easier to port this new implementation to other platforms that want native menus, such as mobile GTK.
  • Our child view and top-level window code is very complicated – some of that we can’t help, but there are steps we could take to make it easier to understand and work with. I’m hoping to do some re-factoring and documentation work for Gecko 1.9.1.
  • We’re planning to expand our widget testing framework to include things like focus testing and more advanced key handling tests.

There will probably not be many new Mac-specific platform features added to Gecko 1.9.1, but there are at least a couple of nice ones on the way.

  • Atul Varma is adding support for HTML data on the system clipboard in bug 428096.
  • James Bunton and others have worked together in bug 125995 to add support for taking proxy settings from Mac OS X network preferences.

Firefox 3 for Mac OS X: Under the Hood

Josh and his grandfather RolandFirefox 3 will be released soon (get the RC here). While the release contains a huge number of new features and performance improvements for all platforms, it is particularly significant for Mac OS X users. We rewrote most of the Mac OS X code that was behind Firefox 2 in order to benefit from modern Apple technologies and fix long-standing bugs. Once you try it I think you’ll agree that the results are astounding. I’d like to explain what exactly we did in this rewrite, how Firefox 3 for Mac OS X is different “under the hood.”

Before I start, I need to explain Gecko vs. Firefox for anyone who doesn’t already know. Gecko is the engine behind Firefox. It provides the capabilities that we use to build Firefox. Under the umbrella of Mozilla, Gecko is actually a much bigger project in technical terms than Firefox is. For example, there is much more Gecko code than there is code specific to Firefox, which is an application we built on top of Gecko. Firefox and Gecko have different version numbers – Firefox 2 uses Gecko 1.8.1 and Firefox 3 uses Gecko 1.9. This post is about changes we made in Gecko 1.9, the engine behind Firefox 3.

The biggest change is that Gecko 1.9 is based on Cocoa instead of Carbon on Mac OS X. There has always been a lot of confusion about what this means, particularly since Gecko 1.9 also happens to include Aqua form controls. It may seem strange to some, but Gecko’s new Cocoa underpinnings and its Aqua form controls are almost completely unrelated.

There are only 2 types of Cocoa objects at the heart of Gecko 1.9 on Mac OS X (let’s forget about the menu bar at the top of the screen for now). Cocoa’s NSWindow allows us to make and control a window on the screen and Cocoa’s NSView allows us to draw things into a window. Those two objects also allow us to get most of the events we need to know about from the operating system (such as key and mouse events). We do not use actual Cocoa buttons or any other Cocoa controls within any Gecko 1.9 windows. The context menus, dropdown menus, the toolbar, the search bar, the buttons and text fields within web pages – they are not actual Cocoa controls. For example, instead of using actual Cocoa buttons for “Submit” buttons we just draw the image of an Aqua “Submit” button into an NSView, one of the basic Cocoa objects we use. Gecko 1.9 has Aqua form controls because we now draw images of Aqua form controls when appropriate, not because we use actual Cocoa controls. The reason we don’t use actual Cocoa controls isn’t because we are lazy or we can’t figure out how to use them or because we are constrained by our cross-platform requirements – Apple’s WebKit doesn’t use actual Cocoa controls for things like “Submit” buttons or popup buttons in web pages either, at least not the last time I checked. IE for Windows is in the same boat. The reason Gecko 1.9 doesn’t use Cocoa controls is for the sake of flexibility – form control behavior and appearance can be changed significantly via HTML, CSS, and JavaScript. Actual Cocoa controls are simply not flexible enough to do all of the things that people want to be able to do with controls on the web.

So if we didn’t get Aqua form controls out of the deal why did we do the Cocoa rewrite? First of all, Apple has deprecated much of Carbon already1 and has made it clear that Cocoa is the future for Mac OS X applications. Apple is investing heavily in Cocoa, which benefits us if we use Cocoa. Cocoa also gives us access to great features that would be more difficult or impossible to take advantage of through Carbon. For example, with Cocoa we were able to relatively easily draw using CoreGraphics instead of the ancient Quickdraw API (more on this later). Secondly, the Cocoa way of doing things matches up with the Gecko way of doing things better than Carbon did. Our Cocoa code is easier to understand and maintain because of this2. This will result in faster development and fewer bugs in the long run. In fact, we actually added more capabilities to Firefox 3’s Gecko 1.9 (such as transparent windows, unified toolbar windows, and an alert service) than we have ever added in any release of Gecko since Firefox 1.0. This is in addition to doing a huge amount of work just to re-implement many of the features that Gecko 1.8.1 had already implemented in Carbon!

Another major under-the-hood change in Gecko 1.9 for Mac OS X is drawing via CoreGraphics and ATSUI instead of Quickdraw. Like much of Carbon, Quickdraw is deprecated and does not exist in 64-bit Mac OS X. Gecko 1.9 uses the Cairo library on all platforms, and Cairo draws with CoreGraphics and ATSUI on Mac OS X. The CoreGraphics drawing API is modern and hardware accelerated, a huge improvement over Quickdraw in terms of speed, capabilities, and code clarity. In addition to using CoreGraphics ourselves, we have made it possible for plugins to use CoreGraphics via NPAPI Drawing Models3. Flash is already prepared to take advantage of this new capability in Gecko 1.9! As for text, using ATSUI allowed us to improve our text kerning and ligature capabilities. It also gives us better glyph cluster positioning, which is good for Indic languages and languages that use exotic combining marks.

I hope this helps to shed some light on why Firefox 3 is a particularly significant upgrade for Mac OS X users. I’m really proud of what we accomplished with this release, it was ambitious and things worked out well. Kinks remain as with all major revisions, we’ll be addressing those quickly in minor updates to Firefox 3.


1 While the deprecated Carbon API is still available for 32-bit applications like Firefox 3, it simply won’t be available to 64-bit applications. Firefox 3 for Mac OS X will not be available in 64-bit but we’re preparing for 64-bit by removing code that won’t work in 64-bit.
2 It might be true that on the whole our Cocoa implementation is more complex than our Carbon implementation was, but that is because our Cocoa implementation does far more than our Carbon implementation ever did. The Cocoa code is still more readable and maintainable.
3 See the NPAPI Drawing Models spec.