Proposal to Drop Mac OS X 10.3 (Panther) Support For Gecko 1.9
I'd like to propose that we drop support for Mac OS X 10.3 (Panther) on the Mozilla trunk. I believe doing so will result in a significantly higher quality release of Gecko 1.9 for the vast majority of users on Mac OS X.
One major part of the development process that comes to mind when I think about the decision to support Panther is QA. There are two major components to our QA resources, community and Mozilla Corporation resources. For Gecko 1.8 there were significantly more Panther testers in the community than there are now. That trend will continue over the next 6 months and almost certainly accelerate when Mac OS X 10.5 (Leopard) is released. By the time we release Gecko 1.9, I suspect that our community Panther testing resources will be so small as to be nearly insignificant. This is dangerous if we expect to ship a product for Panther that we can be proud to put our name on. As for Mozilla Corporation QA resources, we have the ability to allocate significant resources, but those resources could be used much more effectively elsewhere. They could be used on Mac OS X 10.4 (Tiger) and Leopard testing, where the overwhelming majority of our users will be. More on the Mac OS X user numbers for Panther vs. Tiger and Leopard later on.
Dropping support for Panther would also free up engineering resources and allow us to take advantage of APIs that only became available on Tiger. We have made a huge number of great changes to our Mac OS X code for Gecko 1.9, but we still have a lot of work to do and we are already running short on time to deliver a product that works well on Tiger and Leopard. We will deliver a great product, our best yet - but every day counts from here on out. There is already a backlog of tricky Panther-only regressions, bugs, and performance issues in areas ranging from widgets to fonts and gfx/Cairo that I suspect will consume at least a few weeks of development time. Over the next 6 months, especially as QA ramps up for release, the number of serious Panther bugs will go up and thus require even more time. As for taking advantage of APIs that only became available on Tiger, I mean a couple of things. First of all there are some things Tiger can do that Panther can't. Thankfully that is a somewhat short list, but it is not insignificant1. We will have to accept certain non-trivial bugs and/or some missing functionality on Panther. Secondly, there are many things that Tiger can do much more cleanly, efficiently, and reliably2. We will be able to develop a higher quality product for Tiger and Leopard if we were to drop support for Panther because we would not have to spend time adding runtime operating system version checks and reimplementing certain pieces of functionality to work around Panther's API issues. In some places where runtime checks are unreasonable, we can simply move to using better APIs and reap the advantages that come along with that. This information is not surprising - one would hope a newer operating system is better for developers than the old one (you're not going to get a Vista joke out of me today!), but I want to be clear about the cost before we get to the part about the benefits of supporting Panther, which is next.
The only reason we might want to support Panther is to support more users. That brings us to the question of how many potential Panther users we expect to have after November of 2007, our targeted ship date. Unfortunately this is a difficult question to answer accurately, but I think we know enough to confidently conclude that we will have very few potential Panther users by that time. A good place to start might be considering the decisions that OmniGroup (http://www.omnigroup.com/) has made recently. They are a highly respected Mac OS X software company that even happens to produce an alternative web browser. I was able to get 2 significant pieces of information from their website. First of all, as of today, 3 of OmniGroup's products including their popular OmniWeb browser no longer support Panther. OmniWeb probably does not support Panther because WebKit dropped support for it. Secondly, according to the statistics that OmniGroup publishes on their update statistics site (http://update.omnigroup.com/), just under 2% of their users were on Panther at the end of 2006. We don't know exactly why several of their most important products don't support Panther, and we don't know exactly what their update statistics tell us (in large part because half their products don't even support Panther), but without getting into too many nitty gritty details a couple of basic points are clear. They no longer feel the need to invest in Panther support for key products as of today, let alone Q4 2007, and the number of Panther users as of Q4 2006 is probably quite small - less than 6% if you consider 200% to be a generous margin of error in light of only half their products supporting Panther. Aside from the information from OmniGroup, there are several other pieces of information that suggest small and diminishing numbers of Panther users that might be interested in Gecko 1.9. For one thing, people who are still using Panther probably don't have much overlap with the group of people who are likely to download and use alternative browsers. Also, when Leopard is released in October of 2007, there is going to be a spike in the number of people upgrading their operating systems. In part this will be due to Apple dropping support for Panther, which is highly likely. My prediction is that if we were to support Panther with Gecko 1.9, less than 3% of our users would be on Panther.
One might argue that since nobody else is supporting Panther with a new web browser, we should be the ones to fill that niche. First of all, I don't believe we have the resources to invest in such a small number of users right now without paying too high a price with our Tiger and Leopard support. We have some stiff competition on Mac OS X, and Panther support is only going to hurt our ability to stay competitive. Secondly, it isn't as if Panther users are stuck without a modern web browser. They can always use Firefox 2, Safari, or Opera 9.2, all modern and capable browsers.
1. For example, Panther cannot insert images into native menu items once the containing menu is open. This means that we cannot use async image decoding, which is a major problem resulting in missing menu icons. This is due to a bug in the Panther menu implementation that is probably realistically impossible to work around without unacceptable consequences. Another example is that we cannot prevent a menu bar menu from opening when a user clicks on it with a context menu open already. This is the expected behavior, but we can't prevent the menu from opening because the operating system crashes due to a bug in its Carbon event handling. We do not know of any way to work around this.
2. For example, Panther's CoreGraphics APIs cannot handle bitmap data with ARGB formatting. The alpha component must be last. This missing functionality makes some of our graphics code messy and inefficient because we have to "manually" reformat the bitmaps. Another example is rendering a Cocoa NSImage to a particular CG context. Tiger contains a Cocoa method for doing just that, on Panther we have to messily render to a bitmap and pump the data in using CG bitmap APIs. There are many more examples of this type of thing in CoreGraphics and Cocoa. The two examples I just listed are not things that are above and beyond the call of duty - they are things that should be part of any mature API.