13.0 changesets available

13.0 is now in the beta channel and I am typing this blog post in it. The new Blogger is still freaking treacle in January; I'd switch to Wordpress or something else, but Google still owes me some ad buxx and this is where people expect to find this blog, so I just turn the G5 up to Highest performance and type away.

The biggest change people will notice in Firefox 13 (and TenFourFox 13) is bug 598482. This greatly reworks how the graphics stack handles updates by almost totally eliminating the ability to have synchronous painting of the window, and instead connects everything up to the central refresh timer so that paints are batched and executed asynchronously. The result is some noticeable improvements in benchmarks because the browser is doing less unnecessary work (Peacekeeper increases to almost 660 on my quad G5), but there's occasionally a tiny lag in the UI because there is no way to trigger a synchronous paint anymore in the widget library. We notice this more because our title bar is drawn differently than Firefox's is (they use CoreUI; we use CoreGraphics to do it "by hand"); our titlebar is still drawn synchronously, so it appears first, but the rest of the window repaints at a random brief interval after when the refresh driver wakes up. Like most such title bar irregularities, using a Persona fixes it. A definitive fix is simply to rework the theme and the way we draw chrome completely, and I plan to (issue 16), but I'll talk more about that at the end. I expect graphics performance to improve further when bug 539356 lands.

13 also enables SPDY by default. Not many sites are using SPDY; as of this writing the only two big ones were Google and Twitter. SPDY improves network throughput, and it does seem to for us as well, but most of the overhead of rendering Google and Twitter isn't the network, so it's not really much different. There is no way to tell from the browser whether the site supports SPDY, btw; there are a few add-ons that will report the status if you're curious, but since functionally it doesn't differ any from SSL, I don't really see the point.

Another important user-facing feature is that tabs-refresh-on-demand is now default (so that tabs saved from previous sessions only load when you actually go to that tab instead of eighty tabs trying to squeeze out of your DSL line when you start the browser), and the new tab page. I actually don't care much for the new tab page -- it reminds me too much of Safari's, which I didn't like either -- but you can move things around and pin them, and you can also turn it off by clicking the little cube icon at the upper right.

Mozilla made two changes in 13 that I turned off. The first one is enabling smooth scroll by default: this is too slow on all but very simple sites, even on the G5; I might reconsider this after bug 702463. If you already have it enabled, of course, then it is still enabled. The second change they made was to compile everything with -ffunction-sections -fdata-sections, which is ostensibly to help trim binary fat, but caused an approximate 5% regression in just about every benchmark I test with and the small savings in code size are not worth it, so that's backed out too.

In other local changes, I landed a temporary endian fix for WOFF downloadable fonts (so Acid3 works again), and also removed our hack to make WebM decoding multi-threaded because Mozilla's testing seemed to imply it actually makes the current video pipeline slower. (This is not true of 10, so it will remain in the stable branch.)

While binaries for 13 are not yet ready, a number of you have asked for advance changesets to build your own or to play with them, and I will start making them available with this release; here you go.

I have my four eyes on two things in Mountain View. The first is, of course, IonMonkey, the new JavaScript engine. It is now to the point where the browser can allegedly stand up with it, but there are a number of tests that do not pass, and the engine is still not in mozilla-central. Reading the patches, it looks like IM will initially be paired with methodjit+TI ("JM+TI" -- the current JavaScript JIT in Firefox that we also use) in the same way that JM+TI was paired with the old tracejit (r.i.p.), so we should be able to just turn Ion off to start with and thus buy some time to get it working. Tracejit was fully functional for five entire releases (4 through 9), so we can assume we will have a similar grace period to get up to date. Unfortunately, even when IM eventually passes all the tests, benchmark results as of this writing show it's way behind Google V8 and even behind JM+TI, so it is very unlikely to be actually in the tree much before 17 or 18.

The second thing afoot is that Mozilla has started to float ending support for 10.5 again; recall that this was already circulated for the 13 timeframe, but that has obviously already come and gone as mozilla-central is currently on 15. While I still hold that Mozilla killed 10.4 and PPC support way too soon, they have supported 10.5 far longer than I thought they would, and their case is strengthened by Google planning to drop Chrome and Chromium support for 10.5 by "version" 22 -- note that Chromium hasn't been able to actually build on 10.5 for almost a year already.

The current proposal is that Mozilla would end 10.5 support for Firefox 16, but I'd prefer them to end it for 18 so that 17ESR still has 10.5 support in it and we can still use it as a dependable stable release. Since dropping 10.5 means losing a lot of legacy code we depend on (and a lot more work to merge), for 17 we would spin our current widget and theme libraries into Tiger-specific directories separate from Mozilla's code and maintain them independently. We would have to backport some changes required by the cross-platform portion of Firefox as it evolves, but it would be less work than the other way, and it also puts us in a better position for when 10.6 support ends as well because 10.7 has runtime and system requirements we will not be able to emulate. With our widget and theme thus separate from the mainline, I can finally rework how they are drawn, and I am strongly considering using brushed metal to work in better with the OS rather than the slight gradient we use now (remember that we haven't been at visual parity with Firefox since 8.0; if Australis imposed system requirements we would not be able to meet, under this scheme we could simply drop it entirely and continue to develop what we have). If Mozilla ignores us and decides to drop 10.5 in 16 anyway, I may accelerate this timetable. It's not a killer, but it may require us to fall away from them sooner.

10.0.5 and 13 binaries will probably be available in a week or two.