14.0 changesets available and rumblings of Judgment Day

A snapshot of changesets for 14.0 (mozilla-beta) is now available. This is not a major release for Mozilla; about the only user-facing change of significance is that favicons in the address bar are now replaced with a security indicator (globe means insecure; padlock means SSL; green padlock with name means SSL with an EV cert). This is a good adjustment because a common support question is "where did the padlock go? am I secure?" and I think Mozilla got enough of these to reintroduce that reassurance. There are some performance adjustments and a few new CSS features, but other than that nothing amazingly impactful, and click-to-play turned out to be a non-issue for us.

The only other thing to note is that this release also adds support for GStreamer decoding, but it isn't enabled in any released builds, and I am not aware of a prefab PPC GStreamer library we can just use. I am very nervous about us maintaining our own GStreamer; I'd prefer to have that outside of the browser for legal reasons, and be aware that GStreamer only adds the codec -- it does not necessarily improve performance, and QTE will still be faster on those sites it supports. This would just be for those sites that QTE can't currently deal with, like Vimeo.

On our end, however, we have some fires to put out. This version does include the JavaScript compiler latency patch from issue 160 and a crash fix discovered during the investigation of issue 165, and both of these patches will also be in 10.0.6. (Between the latency patch and general improvements in 14, I am now able to blog again with the G5 in reduced performance, which is great for beating the Southern California heat in my home office. Unfortunately, it seems our aggressively small, not-quite-ABI-compliant stack frames are catching up with us, but I'd prefer to delay any invasive surgery at that level until IonMonkey.) Furthermore there are some breaking changes Tobias found in Fx15, so after this I will pull down a copy of the 15 alpha and try to get started on it early (plus, I want to add the QTE as part of the base browser in this release, which is not complicated, but not trivial). However, the biggest problem is that I had to actually comment code out and back out other Mozilla changes to avoid compiler bugs; gcc 4.0.1 is no longer able compile some components in content/ without crashing. Mercifully the code that I jettisoned was non-essential, but it's inevitable we will get something like this in code that actually makes a difference.

We need to also combine this with the Mozilla Mac developers getting more insistent about ending 10.5 support. The current proposal is now to end 10.5 support with Firefox 17, which would really suck, because we would have to add that stripped code back in immediately for what would have been our next stable release on 17ESR. Fortunately I am not the only one with that opinion, and no decision has been made. We need to be reasonable about this; Mozilla has a lot of hacks in their code to deal with 10.5 deficiencies, and it does cause them additional material work in that regard, so I understand their point of view. Nevertheless, if we can get them to hold off on dropping Leopard until Fx18, we will be in much better shape.

These are the first rumblings of what I will call, with my characteristic hyperbole, Judgment Day. Assuming Mozilla agrees to hold 10.5 support through 17, Fx18 will be a major reworking for us: we will need our own theme and widget to escape 10.6+ API hell, we may or may not need to start working on IonMonkey, and we will definitely move to gcc 4.6. All of these foundational adjustments are big-league port changes and will almost certainly introduce bugs and parity gaps, so we'll really need a stable footing for our proletariat while the plumbing gets reworked in the new unstable branch. The only question after that is whether there will be a 24ESR and Mozilla has not said. In my best Arnold Schwarzeneggar voice, I can only say that "we'll be back."