Monday, April 25, 2011

Towards TenFourFox 5 and 4.0.2pre

I'm putting this post out a little early to talk about what we're going to do with Firefox 5 because my hand's been forced a little bit; I've been seeing some well-intentioned blog posters saying, among other things, that TenFourFox is nice and holds the fort but isn't going to get any updates. Besides the fact we just had one, this is unequivocally, unbelievably, unimaginably false. I personally use TenFourFox; I wouldn't shoot myself in the foot by failing even to maintain security updates, let alone additional features. When (not if) we reach a state where we cannot hack "Firefox.next" to build on 10.4 PPC, then we simply carry on maintenance on the branch we know is still working. If nothing else, the browser will remain safe to use even if the technology reaches a state of arrested development. Don't forget that Camino currently uses a three-year-old renderer, but they maintain and land security fixes from later branches to keep the browser safe to use. We'll be doing the exact same thing. I'll discuss that in more detail in a moment.

On that note, let's talk about Firefox 5. Firefox 5 really should be called 4.1 because it is, indeed, the minor feature update to Firefox 4 (as opposed to 4.0.1, which is the minor maintenance update). That said, it does have a number of important features we will want. Very few of these are user-facing, mind you. I've been playing with Aurora (essentially the "stable alpha") on my lonely Core 2 Duo mini, and at a UI level you're not going to see much difference. Like Snow Leopard to Mozilla's "Leopard," Firefox 5 really improves very little of the interface relative to Fx4.

Of the features that are there, however, the most important one is CSS Animation. Remember, Flash or any other plugin will not be enabled in "TenFourFox 5," and in this HTML5 world, we want to encourage animation and graphics methods that do not rely on Flash. CSS Animation is part of that transition away from proprietary, buggy and (in our case) unmaintained ways of doing graphics and animation in the browser. There are also quite a few performance improvements in Firefox 5 that will surely benefit us, because sadly our machines aren't going to get any faster by themselves.

For TenFourFox 5, in addition to getting all that working, I would also like to expand some of our marquee features to add even better performance. For example, the JavaScript nanojit is now stable and has achieved enough cross-processor parity that we can flip it on for the browser as well. In fact, I've been running my 4.0.1 in that manner for over a month (go into about:config, set javascript.options.tracejit.chrome to true), which has been nice and stable, and gives a noticible speed boost at the cost of additional memory needed for the traces. This is kind of a big change to throw at 4.x, but we definitely want it in 5.x. I'm also hoping to finally fix once and for all the problem with our generated prologue and certain kinds of native code calls, which are handled currently with a safe but slower abort to the interpreter. If these calls can be embedded in the trace, we can get even faster, but this has an obvious stability impact and I want extensive beta coverage. Finally, I want to support JavaScript typed arrays in the nanojit; these currently fall back on the interpreter, and the apps that are likely to attempt using typed arrays for increased performance are ironically going to perform worse on TenFourFox because of the fallback. This work has already been done preliminarily. I think this work list is fully achievable, especially because a lot of it is already done or in progress.

In the would-be-nice department, I want to continue our progress towards full AltiVec acceleration of the content chain. We've started (I think very successfully) by enabling AltiVec in libpixman and libvpx. There are some trivial additional code conversions that I can do in libvpx, and I'd like to try implementing them. In addition, Fx5 adds libjpeg-turbo, which is already faster in and of itself, but also gives us the chance to convert the MMX/SSE code it includes into AltiVec/VMX. This should greatly speed up our image display and processing. Finally, I want to track down other places in the code where Mozilla has already implemented SSE or SIMD equivalents for C code and write VMX versions. This work is unlikely to be fully completed for TenFourFox 5, but some parts should make it.

As I alluded to previously, Firefox 5 is not a slam dunk: we need to get Chromium IPC working on Tiger. I know it's possible to get it to compile, but linking was historically an issue because with IPC everything is clotted into a huge superlibrary called libxul (and in debug mode, this was too large for Tiger's linker to pull together), so it has never been tested. Fx4 does not require it (just strongly encourages it), but Fx5 demands it. Again, I remain cautiously confident the port is possible, but even if it is not, let me reiterate again that even if we remain stuck on Mozilla 2.0 forever, we will still get security updates landed on TenFourFox and the browser will remain functional and safe. You have my word on it: I eat my own dogfood. I hope that Classilla's longevity and update history demonstrates to people that TenFourFox is here for the long haul too.

That aside, Fx5 sounds pretty good, right? Well, don't get too raring to go just yet, because we have to consider the ramifications of the migration. Since our last discussion on this topic, more information has become available, and most of that information from our perspective is bad news. Fx4 will be the last of the "big" releases and the last to retain the old release EOL timeframe, which is usually six months of updates after release of the next version (and you can bet that under the new rapid release framework it won't be a second longer). Fx5 and later will be unsupported the second the next version comes out.

What does that mean for support? Well, barring something extraordinary, as soon as Fx6 emerges there will be no more Fx5 updates. Period. Similarly, when Fx7 comes out (!), no more Fx6. This means the safety net that would ordinarily be under us with a stable branch like Fx4 will no longer exist once we jump to Fx5. If there is a serious bug discovered in Fx5 and Fx6 has already come out, then there will be no fix for it in Fx5; Mozilla wants you to simply update. This is not ill-conceived on their part, but it sucks for people like us trying to actually build around the updates because the ground keeps shifting under our feet, and may require us to do a significant amount of backporting. I'm also not sure what this will mean for extension compatibility. Mozilla has plans in place for carrying forward addons semi-automatically, but if this process cuts off backward compatibility for old versions at the same time (as, possibly, a carrot for updating), that could really bite us.

To balance this and to spare much unnecessary work, this is how the rollout will happen, assuming the port of Fx5 is successful.

- Work on TenFourFox 5 will not commence until Firefox 5 is released. Other than chemspill releases, we know no more work will occur on the final release branch once it becomes final because the next 6-week release will clobber it. Therefore, we know nothing is going to change for Mozilla 5, and this simplifies our porting.

- Until work begins, there will be 4.x updates, and at least one more 4.x release (4.0.2pre; we'll get to that) will have feature work.

- Once work begins, we will have our own separate formal betas, just as before. I envision no more than three, most likely. 4.x updates will continue simultaneously as pure security and stability updates only.

- Once we are final, we will publish a limited set of 5.x security and stability releases while we look at Firefox 6, which should be out by then or soon. I am working on getting security access at Mozilla so that I can review and backport security fixes as they happen, though in the short term we can still get this information from publicly-available Mercurial commits, and they will land on 5.x too.

The cycle will then repeat as long as we are able to compile Firefox.next, whatever it happens to be. If we jumped to Firefox 6, then there will be 6.x betas (with 5.x releases), followed by 6.x releases while we look at Fx7, and so forth. In essence we will be emulating the old Mozilla release mechanism, except that we will be actually maintaining our own old branches instead of relying on Mozilla to do it for us.

At the point where we can no longer move forward, we set up our own Mercurial repo and maintain the last good branch "forever," backporting all security fixes that apply, any bug fixes that apply, and (very carefully) new features that we might need -- limited largely to browser core, layout, content, DOM and JS. JavaScript is pretty straightforward to keep current, fortunately, because it is largely self-contained. The rest will be examined on a case-by-case basis. This is what I've referred to as security parity and feature parity in the Wiki.

I really hope this puts people's concerns to rest; TenFourFox is here to stay. I need a browser that works on my G5. You can rely on this because I have my own skin in the game, as do, presumably, others who have contributed and who will contribute in the future.

Now, about 4.0.2pre. This is a feature release, but with only one feature, which is to try new compiler settings. Since this can lead to very subtle bugs, I really want to keep everything else constant to avoid nasty little variables I can't control for. Part of this will be to enable -ftree-vectorize for G4/G5 and attempt a proper 32-bit compile for G5 without using the hackish hybrid compile string we use now (64-bit Firefox on G5 still has issues and we don't really benefit from 64-bit anyway in the same way that x86 does). This won't affect the G3 releases, obviously. Similarly, it will include whatever other fixes for Firefox 4.0.2 that Mozilla has landed. By the way, they are holding their official release of Firefox 4.0.1 until later this week due to a last-minute issue, but this is apparently an oddiment of their update infrastructure and does not concern us. 4.0.2pre will be available when Mozilla releases it to the beta channel and I'll give you a heads up when it is about to arrive.

Well, that's enough blather; if this does not put your questions to rest, ask them in the comments.

22 comments:

  1. Dude - you're awesome. Thanks, mate. :-) I really appreciate this.

    ReplyDelete
  2. I'm very thankful for what your are doing. From me and my family a BIG, BIG thank you! We have one in excellent working condition G3 with two G4 (Maman and Papa) and one G5 that my girl friend love.

    ReplyDelete
  3. I'm thankful to you for your great work.
    Thank you!!

    ReplyDelete
  4. Great work and I am thankful. Question, is anyone else having a problem with 1Password not working with TFF?

    ReplyDelete
  5. Thanks for the kind words, everyone. noodles168, yes, 1Password does not work with 10.4Fx. As near as I can determine, 1Password needs to enable this support (their support for Firefox 4 should suffice; once they add TenFourFox to it, it should "just work"). If 1Password requires something done for TenFourFox, please point them my way and I'll see if I can do it for 4.0.2pre, but as far as I can tell I cannot enable it for them.

    ReplyDelete
  6. Great post CHC, looking forward to libjpeg-turbo and CSS animation in TFF5 :D This is the kind of thing I hope to do some day. Taking or writing software and fine tuning it. It's like working on a car, but not as greasy! :P

    Keep up the awesome work CHC, I will be patiently waiting. ;)

    ReplyDelete
  7. I asked Agile a few weeks ago about supporting TenFourFox and their response was, "Unfortunately, the Firefox 4 extension is Intel only. We are not likely to develop the PPC version of Firefox 4 extension since there may not be any PPC versions officially supported by Mozilla."

    More recently I saw this response directed toward someone else who asked the same thing, "We won't be adding support for TenFourFox or any other non-Intel builds of Firefox 4."

    ReplyDelete
  8. Can future releases also always include a German Version? Thanks a lot! ;)

    ReplyDelete
  9. Ive an issue i cant solve... since ive updated from original FF to yours, it wont remember (keep) all the open tabs when i hit apple + q. In previous versions it was supported to do so, but i havent found any option in the preferences to get a workaround. Is it a bug or?

    ReplyDelete
  10. Dr Tony, I had a feeling they would say that. That's a shame, and I think we'll start hearing more of that from extension developers who compile binary components; furthermore, now that Xcode no longer compiles for PPC, there's no way for them to support it even if they actually wanted to. Thanks for enquiring, and I'll make a note about it in the FAQ.

    Impact, they can if someone translates it -- ich kann nur ein bisschen Deutsch :P See issue 42 if you would like to help.

    In reference to your second question, this is why I always ask people to check their bug reports against real Firefox 4. This is one of those "controversial changes" Mozilla made and it affects all Firefox 4 derivatives, including TenFourFox. Here is a workaround: http://notboring.org/devblog/2011/03/how-to-make-firefox-4-remember-your-open-tabs/

    ReplyDelete
  11. About the translation (German): Which strings would need to be translated especially for Ten4Fox? I can do this, I'm a professional translator anyway. For the rest, obviously the strings from Intel-FF4 would be used, right?

    ReplyDelete
  12. This comment has been removed by the author.

    ReplyDelete
  13. Some compiler related things: are you aware of the availability of gcc-4.2 for 10.4?
    The tarballs available on http://r.research.att.com/tools/ contain the latest version of gcc-4.2 that apple provided for 10.5, ready for use with Xcode (Xcode only has to made aware of the presence of gcc-4.2 but there's a way to do so). Using that version of gcc-4.2 I could build (on 10.4) the complete WebKit from webkit.org and the resulting code works flawlessly (I'm typing this message using that self built WebKit).

    ReplyDelete
  14. I was peripherally aware of it, but thank you for the link. However, switching compilers is definitely not something for the stable branch. We'll probably make the jump when we require a 4.2+ feature.

    ReplyDelete
  15. whoops, forgot the other. chtrusch, probably easiest to look at what the French translators are doing, and work along the same lines (see issue 42 also).

    ReplyDelete
  16. Alright. I noticed that official FF4 packs everything into an omni.jar file, while Ten4Fox still maintains the old structure of single jar files. What's the difference.

    ReplyDelete
  17. Im downloading my TenFourFox copy now, I'll try to run it on my 10.5.8 G4. Thanks dude..

    ReplyDelete
  18. great work guys
    but which flash and/or shockwave plugin im gonna use?
    10.4Fx 401
    PPC G4 10.4.11

    ReplyDelete
  19. In TenFourFox 4.0.x, you can still use Flash 10.1; plugins are still enabled, just deprecated. This will apply to 4.0.2 and to any future version of 4.0.x.

    In TenFourFox 5 and thenceforth, however, plugins will be disabled by default. It is quite possible that they might not even work even if the code were kept enabled, because Mozilla is already moving away from the classical NPAPI model. There will be a pref you can flip to turn them back on, but support may cease to function at any time.

    Blame Adobe and Apple for this; there will be no Flash 10.2 for PPC, and you can bet QuickTime will be unsupported on PPC as soon as Lion comes out. This is why I'm making Flash alternatives a priority for 10.4Fx 5.x.

    Unless "someone"(tm) is developing a Flash alternative that is supported for PowerPC, and if so please talk to me right away, Flash and all other plugins are scheduled for destruction in TenFourFox for security and stability, and there will be no Flash anymore. It is IMHO the overall best choice of multiple bad options. For now, plugin support remains as legacy support in 4.0.x. Install Flashblock now, and get accustomed to a Flashless browser.

    ReplyDelete
  20. Regarding the difficulties you encounter when linking libxul:
    Would you like to try the new linker and binary utilities that Apple ships with Xcode 3.2?
    With some help from MacPorts and Gentoo Portage I got those packages compiled and I could build working gcc-4.2, llvm-gcc4.2 and clang-2.9 using those tools. The tools are linked against the 10.4 universal SDK so there are no dependencies on MacPorts nor Gentoo Portage. All that was done on Tiger itself and Xcode 2.5.
    I think it's worth a try! I can't test if it works with ppc64 architecture as well.

    I also managed to build the latest version of gcc-4.0 that Apple provides(build 5493; Xcode 2.5 ships with build 5370).

    ReplyDelete
  21. Tobias, send me an E-mail about your linker. I'd prefer not to also update the compiler, but I'll try a new ld64 (assuming it has no dependencies as you say).

    ReplyDelete
  22. Hello:
    First of all I want to say to you and your team a big "Thank you", TenFourFox isn't my main browser yet, but I'm working on that :-)
    On the other hand, I bet many people asking about "security updates" must be using Internet Explorer without any kind of worries...
    Best wishes, as always,

    Federico (aka euskir)

    ReplyDelete

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