Mozilla developers readying one more beta cycle for Firefox 3.1

Serious issues evidently remain with recent builds of the latest edition of Firefox, leading developers to propose a new Beta 3 cycle, but with the aim of not delaying the new browser's final release.

With quality assurance tests now under way for Beta 2 of Mozilla's open source, cross-platform Web browser, the general public may see the latest fruits of developers' labor the second week of December, according to the findings of an organizational meeting yesterday. That's a few weeks later than originally anticipated, though delays of that short a period are not unprecedented.

But one possible reason for that delay, which could end up producing further delays down the road, is a steady rise in the number of blockers -- catalogued bugs that are deemed serious enough to prevent code that contains them to be "frozen" prior to a milestone release. The blocker count goal, naturally, is zero; but a graph released yesterday shows that number now approaching 250, with the nomination count for prospective new blockers as of yesterday standing at about 130.

It's a situation serious enough for lead engineers on the project to recommend the introduction of a Beta 3 milestone, which the organization had not originally planned for.

"We don't have full clarity into the nature of our remaining blockers, some of which likely require beta exposure," wrote Mozilla engineer and resident "phenomenologist" Mike Beltzner in his official report yesterday. "In order to close this release, a re-triaging (like we did around Firefox 3 Beta 4) is required both to identify the severity of the remaining blockers and the time required to address them properly. Further, the impact of late Beta 2 landings such as Private Browsing Mode, Worker Threads, Speculative Parsing and TraceMonkey will benefit from multiple beta releases."

"Landings," in this case, refer to new features that the team floats around the release schedule in order to find the best place to premiere them. Private Browsing Mode is perhaps the most eagerly anticipated of these landings, especially with Internet Explorer 8 Beta 2 and the current builds of Google Chrome already featuring their own versions.

But also, worker threads will give JavaScript programmers functionality that's typically been delegated to the C++ realm: essentially, the ability to fork a thread for code that does not directly access content on the page, as a way of introducing parallelism and increasing performance. (Chrome has been experimenting with this as well.) Speculative parsing will enable Firefox to give more educated guesses as to the meaning of an entry in its all-purpose address bar, based on partial entries. That, coupled with the browser's new TraceMonkey JavaScript engine -- which uses just-in-time compiling for the first time -- could potentially accelerate version 3.1 by orders of magnitude for some operations.

That makes the 3.1 version perhaps at least as important for Mozilla as the 3.0 version. So an extra beta cycle may very well be warranted. The problem, however, rests with supporting all those other developers who support Firefox -- those who have to adjust their add-ons. You see, add-ons are (like much of Firefox itself) JavaScript apps; and with a much faster JavaScript interpreter under the hood, add-ons' behavior could be severely affected.

If Mozilla adjusts Firefox's development schedule, outside developers may need to be re-informed as to what milestone version they should target when making their behavioral adjustments. That was on developer Michael Connor's mind yesterday.

"I think that if the current way is broken, and this enables a more stable and reliable addon, we should tell addon authors that this specific piece needs work, and [Beta 2] should not be their target for that specific functionality," Connor wrote. "If the implementation of a new feature is flawed, we should tell addon authors that we're fixing it and just do it, rather than ship a substandard [implementation]. This would obviously need to be done by b3, of course."

At this rate, Mozilla's Beltzner suggested, the "code freeze" for Beta 3 could be set for January 2009.