Yesterday, I opined how Firefox on OS X does not behave like a proper Cocoa Mac app. That’s because it truly isn’t, however, I didn’t go into the technical details as to why — though this was for the sole reason that I assumed most readers are technical enough and already were aware of the reasons.
On that note, I received a very thoughtful piece of reader mail this morning, and Justin gave me permission to share his comments.
To make a long story short, from what I currently gather and understand, Firefox doesn’t hook into the system-level UI toolbox in the Cocoa API the way conventional Mac apps are. As a result, Firefox doesn’t use NSToolbar for its toolbars, and the URL field doesn’t use NSTextbox, the way Safari or Camino do. Firefox instead uses a custom UI layer based off of XUL. This is what allows Firefox to be easily skinnable/themeable, and it’s what allows for Firefox to maintain some level of UI coherency among Windows, OS X and Linux (KDE/Gnome). Opera also takes the same approach, and it’s why in both cases, the developers had to rely on a UI designer to custom create a default OS X theme which approximated the basic Mac UI conventions as closely as possible. This means that Firefox is a poor Mac OS X citizen by design, to accommodate theming and cross-platform compatibility.
That’s why Camino was such a compelling alternative (and continues to be a compelling alternative to me). By essentially embedding Gecko in a Cocoa shell, they created a browser which has the same engine and the same power as Firefox, while at the same time obeying and using all of the Mac’s UI conventions and features (but it also is the reason why Camino never supported theming or plugins, one of the most heavily demanded features made for Camino). Sadly, with the Mozilla developers ending support for Gecko embedding, and with development of Gecko far accelerating past Camino, this is all coming to an end sooner or later.
Justin is spot on, however, I’ll also reference a great piece by Mozilla Gecko engineer, Josh Aas. This is worth a re-link, as it’s a couple years old, however still holds water in 2012 as far as Firefox is concerned.
We dropped ATSUI for text rendering and moved to Harfbuzz and Core Text. The move to Harfbuzz for many operations was done for security reasons and in order to expose advanced typographic features. Font handling is difficult in general, and even more so in web browsers. We’d prefer to depend on open source font code if possible because we can patch it quickly and participate in improving it.
We also added support for the Cocoa NPAPI event model and the Core Animation NPAPI drawing model. These specifications are a big step forward for browser plugins on Mac OS X. They are easier to develop for, properly documented, and designed with IPC in mind. As of version 10.1, Adobe’s Flash plugin supports Cocoa NPAPI. Which leads me to the next improvement…
Firefox 4.0 marked a monumental improvement for Mac users. As Josh explains in his piece, many portions of the app that weren’t written with Cocoa APIs, were in fact re-written. That being said, the user interface is still by and large built from Mozilla’s XUL. For various reasons of good cross-platform compatibility and reasonably fast deployment, I can’t see Mozilla forking the Mac version of Firefox and rebuilding the entire interface using only Apple’s tools. This would be a massive undertaking, and I get the feeling that this isn’t something that Mozilla is willing to do at this point. I’m confident that the people working on the OS X version have absolutely good intentions to continue to improve it. One only need look at the Firefox nightly builds to see how much work is going into the UI/UX of the app.
As always, I will continue to try future versions of Firefox. From what I’ve seen in the latest nightly builds, it’s going to get a hell of a lot better real soon.