Wednesday, July 16, 2014

24.7.0 released (so long), plus: Mozilla tries to double their pleasure with new Electrolysis gum

24.7.0 is released (downloads, release notes), the final release for TenFourFox 24. Please check it for sanity and wave it goodbye into the sunset as it will be offered only as an interim download for those who do not want to upgrade to TenFourFox 31 yet.

I'm now working on the final build for 31.0. Issue 280 is fixed in this release for G5 users, the only remaining major issue; a minor cosmetic annoyance on low end Tiger systems is issue 282 but this can be dealt with during the release cycle. It looks like generational garbage collection was too crashy, so Mozilla has reverted that and ESR31 will be (like us) exact rooting only. This is good news, because serious problems outside of GGC now have a much better chance to get fixed since both B2G and ESR31 won't use it.

Thanks to Chris T's hard work and our localizers, we have the same set of language packs for 31 that we did for 24, which is great. Also, I'm going to include a link to the Japanese translation, which is maintained outside of our framework. Although Yosemite is still technically in preview, I'm going to rip it off early (minus that freaking annoying cloud animation) like we did for Mavericks since the whole design-change thing fits in perfectly with the Australis shift. You'll enjoy the pastiche.

Chris has also proposed finally turning on pdf.js, Firefox's built-in PDF renderer, as default. We disabled this originally for performance reasons, but it looks like the JavaScript and graphic rendering improvements make it at least usable. This won't happen on 31, but it might happen on "" (33 or FPR1, depending on what I decide). If you want to try it, toggle pdfjs.disabled to false (you may need to restart depending on what add-ons you have). It won't be as fast as the built-in PDF renderer in Preview, but the convenience may be worth it. What do you think?

I'm monitoring future changes in Firefox and there is a lot of activity around resurrecting the foundered Electrolysis (E10S) project that was originally scheduled for 4.0 way back when. Electrolysis, put simply, is multi-process Firefox -- chrome, i.e., the browser interface, runs in a separate process, and content, i.e., the websites you visit, runs in (at least) another. This improves security and responsiveness dramatically, but could use substantially more memory, may be overall slower on uniprocessor Power Macs (such as all PowerPC laptops), and might not even work. Right now, E10S will crash TenFourFox because the 10.4 SDK doesn't implement the process spawning library routines -- we have to do that ourselves (issue 66) -- and if we do it, there might be a whole class of new bugs to deal with since we don't know if there are endian issues with passing information or serializing objects and there could be operating system bugs that get exposed in the implementation. It would only be a net positive if it didn't suck, though that's true of everything, I guess.

Mozilla is pushing Electrolysis as a marquee security feature for Pwn2Own 2015, which is roughly the Fx35 or Fx36 timeframe. Usually once a major architectural change becomes default, the other code path is quickly deprecated or deleted (and certainly unmaintained), and we would be at least two releases shy of the next ESR (Fx38). However, given the amount of work needed to even make it workable for Nightly users and the chaos it will cause with add-on incompatibility, I think it will be even longer before it becomes default in Nightly (and the countdown begins).

Make no mistake: I support, in broad strokes, what Mozilla is doing and it solves a whole class of bugs for them they can't solve any other way with the current single-process architecture. But it might not be a good thing for us, and it would require a lot of work with no guarantee of a payoff. If they enforce it and I can't make it work, that's a portkiller. We also need to watch what's going on with 10.6 support -- I'm still predicting it will be removed somewhere in this inter-ESR timeframe and I bet 10.7 support goes away at the same time. We're still relying on much of that old interface code and having to backport and merge all of it along with the 10.4/10.5 compatibility code we already have would be far more work than I could reasonably accomplish on the rapid-release timetable, at least as it stands right now. Watch Chrome very closely, because once Google gives Snow Leopard the axe, Mozilla will almost certainly follow suit.

Expect 31.0 final by this weekend for an on-time release next Tuesday.

No comments:

Post a Comment

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