Thursday, June 16, 2011

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:


  1. Used the browser all day, found no issues. Nice to see TFF developing successfully.

    "Direct" PDF viewing would certainly be great. The Schubert PDF plugin has some (workaroundable) issues already with TFF 4 and 5, as well as Seamonkey 2/FF 3.6, although I still prefer its method of just using OS X's capabilities. This ensures perfectly correct layout, which I doubt the JS method will ever reach. On the other hand, just for reading, I'd take some gliches in exchange for faster scrolling any day.

    I had some spare minutes today and made the German language pack installer for 5.0RC (if the RC becomes the final version, the installer can be used for the final version as well, of course).

    Oh, and: Be cursed, Chrome!

  2. Excellent!

    After writing that all up about 4.0.3, there is some rumbling under the hood at Mozilla about moving up their timetable for 5. If Mozilla decides to post 5 early, there may not be a good reason to run off a 4.0.3 unless there is heavy demand, because each release costs us space and I'd presume people would want to get 5 instead. It doesn't change what we do with 5 itself, however; I'll post something when Mozilla management has come to a decision.

  3. ... aaaand word just came down; Fx5 still comes out 6/21. So we'll proceed as written above.

  4. Looks good. Sometimes the bookmarks bar gets "confused". I cannot rightclick a bookmark, and the shading does not appear when I hover. Scrolling to the top of the page usually "resets" this condition.


  5. Another point to consider with the rapid version number switching is that websites that still live in the 90s, serving different code to different browsers, need to be updated more frequently. Right now, Apples own doesn't seem to know about us, so their horizontal menu with the hardware models doesn't work correctly unless I switch the user agent string to Safari 5 or the like. It does work in 4.0.2, however, with the default user agent string.

  6. Used every day, nice job!
    i found it faster than competitor and now so stable.
    just one little request/explanation: isn't possible use "mactube-engine" to playing youtube video?

  7. html5 video on youtube is getting much better. using emac G4 1.42Ghz 1Gig ram.

  8. This comment has been removed by the author.

  9. @benzo, no, because it is not configured as an Internet plugin.

  10. I'm trying to post here, but the posts don't stick. Sorry.

  11. I found a strange bug which, again, I'm unable to test against FF Intel due to lack of an Intel Mac.

    If you have the Bookmarks Toolbar and/or the Web Developer Toolbar (anything with submenus/folders), you can hover these left and right when they are open. See the video below, I don't know a better way to describe this. If you do this for a while (about 10 times right and left), the TFF Menu bar (including the Apple menu) stops working until you restart TFF. Other applications are not affected. When I rightclick the nonworking Menu bar, I get a contextual menu that I should get when rightclicking a toolbar in the browser window. I made a reduced testcase bookmarks file with only empty folders.

    testcase bookmarks file:
    video (how to trigger the bug):

    Additional information:
    Machine: PowerBook G4 1.33 GHz (7450), 10.5.8
    Created new OS X user account for testing; there are no haxies installed on this machine
    The content of the folders in the toolbar doesn't matter, they can even be empty
    It doesn't matter if nanojit for chrome is enabled or not.
    It also happens in TFF 4.0.2., but not in Seamonkey 2.0.x
    It doesn't seem to happen on G3 with 10.4.11 (at least I was unable to trigger it)
    It does happen reliably on G4 with 10.5 (but I don't know if it's the processor type or the OS)
    I don't know if this is a TFF, Mozilla, or OS X bug

  12. That one did ;)

    I'm getting the posts in my E-mail, so they are getting sent, but Blogspot is eating them. Just go ahead and open an issue and I'll track it.

  13. This comment has been removed by the author.

  14. This comment has been removed by the author.

  15. The post seemed to be too long. Okay, I'll open an issue.

  16. How would you imagine using TenFourFox as the primary browser if it didn't support plugins i.e. Flash anymore? I wouldn't.

  17. @niu tech: It's hard to imagine for me as well. We all (most of us) depend on plugins right now. But in 2001, it also seemed hard to imaging a world with websites working in all browsers and not just IE on Windows. Try to think more into the future. Let's see were this all leads with html5/iPad also going in that direction.


Due to an increased frequency of spam, comments are now subject to moderation.