5.0 RC released, 4.0.3 plans, and onward to 10.4Fx 6

For 5.0 we actually have a true RC, which I have released as (surprise surprise) version 5.0. If there are no major problems, then it will simply "become" the release version. The RC fixes issue 68, which turned out to be a JavaScript error Mozilla introduced that only affected us because we are pure tracejit (methodjit and tracejit together don't have the problem), and was fixed in bug 663789. It just so happened that pages that dynamically instantiated plugin elements were the most badly affected by it, but other pages could trigger it, and this doesn't change my intention to disable plugins by default in 6.0. However, no major issues have occurred with plugins otherwise, so 5.0 will be their last stand.

On or around June 21st, the following will happen:

• The RC will become the final release, assuming a respin is not required. (If it is, you will be prompted to "upgrade to 5.0." Just do it, trademark of Nike, Inc.) General users will then be offered it.
• 4.0 users will be also offered 4.0.3. This is a security update for 4.0 and will be the last of the 4.0.x TenFourFox releases. It will also have the fix for issue 63. They can choose to stay with 4.0 if they have extensions that require it, or jump to 5. Note that we will be somewhat forcing people to stay in update order; i.e., if you skip 5, you will be still offered the update to 5, which you should do; then update to 6. The reason is to allow the browser to rebuild certain databases that may change from version to version.
• Builders: new patches against mozilla-release instead of mozilla-beta will be available at that time as well. I expect little or no changes, but you should use those patch sets and that repo. If Mozilla offers source for Firefox 5, then we'll work up a wiki document about applying your changes to that, because mozilla-release will be unmaintained, used only for chemspills, and will be overwritten by the next version. If they do not keep a source tarball around -- which admittedly would not be SOP for them -- then we will have to and our tarball will have the patches already applied.
  

With regard to the security aspect, the rather spectacular Firefox WebGL video memory access exploit that has been making the rounds thanks to an (IMHO) rather impolitic and indiscreet disclosure does not affect us, because we disable it at the code level.

Onward to 6. Unlike the transition from 4 to 5, there is a lot more in the transition from 5 to 6 due to a full refresh cycle. However, we are less likely to have the initial panic I had trying to get 5 together because we are now compatible with the current Mozilla build system using Tobias' ported linker and I am not aware of any large changes in that, in IPC or in NSPR, so the odds of jumping to 6, while never guaranteed, look pretty good.

For 6, Tobias has investigated accelerating JavaScript by compiling it with vectorization. My initial attempts to vectorize the entire browser were shockingly unstable, but his initial tests with just NSPR and JS in issue 52 look promising and yielded around 10% improvement in benchmarks. We'll need to make sure that the same thing applies for stock gcc 4.0, however, and unfortunately our G3 friends won't get this benefit since it requires AltiVec. We will also want to bang on it thoroughly for the kinds of subtle errors such compilation can introduce. Once this stabilizes, and assuming it works, it's time to start thinking about porting methodjit to PPC and taking advantage of even more power, since IonMonkey is still a good couple of iterations away.

Plugins will be pref-ed off in 6 and there will be more switches for that so that you can at least still use them in 6, or use them in less unsafe situations, albeit without a safety net. By 7, however, I have a pretty strong premonition that they will break in major ways. We'll see. Even though we "have" IPC in 5.0, it is a gutted and almost completely non-functional IPC library in 10.4, present merely to make the build system happy and give it something to link against, and so plugins remain in-process.

Towards the end of a plugin-free existence is this remarkable proof of concept from the Mozilla team on implementing PDF viewing in JavaScript. Not merely a simple renderer, the code actually turns the PDF into JavaScript and executes it -- a genius idea, because the JS generated will also be accelerated, making PDF rendering remarkably fast. Although his demo has some obvious graphical glitches still, it is amazing how well it works even in this embryonic state. Look for it as an add-on coming soon.

Speaking of, a number of you had voiced concern about Mozilla moving too quickly with version numbers and leaving extensions behind (part of why I'm hedging our bets a little with 4.0.3). It does certainly seem like this is on Mozilla's mind as well, which is the apparent reason behind a meeting on risk mitigation they have scheduled before the formal Firefox 5 release. However, it appears clear that right or wrong, good or bad, rapid release is here to stay. Let's all curse Google Chrome together.

Release notes and builds for 5 RC:

• G3
• G4/7400
• G4/7450
• G5