There are no changesets for 10.0.8 because the 10.0.7 ones applied cleanly, and I have decided not to do any more backporting for this release. I might add issue 130 to 10.0.9, but I haven't decided yet, as it is a minor nuisance bug.
For the 17 beta, there will be a couple significant changes. More on that soon. Also, there will be a new QTE release for 17 with some fixes.
17 is really very nice. Graphics performance is significantly better and I also took the liberty of pulling a couple low risk bugs from 18 to speed up the URL bar completer (bug 781588 and bug 794520). There is also an integrated debugger and lots of new development tools, and quite a number of bug fixes, though pdf.js is still not ready for prime time.
On our side of the fence, 17.0a2 repairs bookmarks search, which was an endian problem since 13.0 (issue 177) and a long-running nuisance with the manual update window not properly handling No Thanks, which sounds like a feature but actually isn't (issue 130) and which will be backported to 10.0.8.
We also have a mitigation (issue 171) for people who were bitten by Tenderapp problem 2 and fonts just corrupt enough to still be useable by the OS but fail in Harfbuzz, which is the OpenType shaper used in TenFourFox (ATSUI, which was used in Firefox 3.6, is not suitable for Firefox 4+, and the secret CoreText in Tiger does not support enough features to be useable for this either). Ordinarily corrupt fonts should be simply disabled in Font Book and the font cache cleaned out, as they could be problematic for other apps. This is hard to do with common fonts like Arial, Helvetica and Times, so now you can set a pref in about:config to tell TenFourFox to find another font (tenfourfox.gfx.badfont.arial, tenfourfox.gfx.badfont.helvetica and tenfourfox.gfx.badfont.times, respectively). You can combine them into a set if you like, or disable all three of them. Please note I can't predict what font it will pick because that depends on what you have installed; it will find something it thinks is similar, which might occasionally be totally wrong, but should at least be legible. Please note that most users will not need this and in fact I have never been able to reproduce this on any of my machines, but there are enough people with this issue in some manner that hopefully this mitigation will help them if they cannot disable the font otherwise. After setting one or more of these preferences to a new value, please restart the browser. I will consider adding other fonts to this list, but they should be ones that people cannot disable easily -- I do not want a whole string of font exceptions in the code.
There is at least one major bug in 17.0a2, but we do have some time to rectify it; apps that do a lot of canvas painting and animation don't update properly. This is really a Mozilla bug (bug 794337) but I am concerned that now that Mozilla has dropped 10.5 for 17+, they may not fix the problem since every supported Mac now is capable of hardware acceleration and this is only a problem for systems that are not hardware accelerated -- like us. So we might be going it alone on this one, although I did find a regression range to help speed up finding a fix.
As threatened, 17.0.x will be the final version to support building with gcc 4.0.1. The fixes required to get the browser to build and link with it are now voluminous, and I even discovered at least one miscompilation which was totally wrong and had to be rewritten. While 17.x will be built with 4.0.1 for the remainder of its life, this is the end of our use of Xcode-based gcc. Mozilla, in fact, is now requiring clang to build at all on OS X, but we will short-circuit this, of course.
In other Mozilla news, the IonMonkey has landed in Firefox 18, the new JavaScript engine for long-running apps. I wish I could be more positive about this, but the numbers being posted are not as impressive as I would like even on the core Tier-1 platforms, especially given the large amount of work that will be required to port IonMonkey to PowerPC. IonMonkey really only significantly runs, and benefits, apps with relatively long runtimes; "old" JaegerMonkey with type inference handles most of the rest. Nevertheless, it's going to be an important part of future versions of Firefox and I am exploring what work needs to be done for our port to be successful. The silver lining is that it does offer additional optimization opportunities that JM+TI do not, and like JaegerMonkey during the TraceMonkey days, we don't need to implement it yet.
Mozilla is also putting the final touches on 16.0, the last version of Firefox to run on 10.5, and this will probably also be the end of SeaMonkey-PPC unless hikerxbiker starts doing his own local changesets to deal with that (right now the browser is more or less built "vanilla", and the ESR as written will not run on 10.5 unless it is modified). Given the pattern of dropping support before an ESR, it seems probable that Fx23 will be the last version to support 10.6 and "real" Mac OS X since 24 is prospectively the next ESR after 17. When Mozilla requires 10.7 as a minimum, we're going to be in hot water because every system will not only be hardware accelerated, but also 64-bit, and 64-bit builds on G5 have not worked out very well (and would exclude our many G4/7450 users). That's a very likely time to think seriously about dropping to feature parity.
If you are interested in localizing 17, now is the time to get started. Chris continues to head our localization efforts in issue 42.
I will be releasing a 17 beta to general audiences next month, after 10.0.8 comes out for stable-branch users. Watch for it then. Please test 17 carefully against any tier-1 platform, since there are still some significant Mozilla-general bugs present that they need to repair, as is typical for Aurora. Enjoy.
Update: builds now available. Get.
There is a lot of scrambling with the browser authors about what to do with a new 0-day Java exploit that is circulating and is already part of at least two penetration toolkits. The flaw only exists in Java 1.7, which was never distributed with any PowerPC version of Mac OS X (though you can install an OpenJDK version of it), but because of other flaws you should make sure that the Java plugin is off and of course we "ship safe" because plugins are already disabled by default anyway. If Mozilla chemspills for this issue, we will probably not follow suit unless there are other changes related to it we want to capture.
Review of the two bugs indicates one minor one, and the other one actually broke the tree at least once and is being watched for fallout on the ESR branch. This does not sound appropriate to land on the tree so late, I'm not going to go through 8 hours of rebuild for a minor issue and an issue that may cause us to rebuild later, both of which were in 10.x all along, and neither one appears to in and of themselves have a security impact. We will pick this up with any rebuild and/or scheduled 10.0.8.
Please try 10.0.7 on your system(s). It will become final on Monday.
Of note, Mozilla themselves disabled pdf.js prior to release, so it looks like it wasn't really ready for primetime after all. The interested can still reenable it from about:config.
Real life and a paycheque is interfering with my hacking time, so 10.0.7 will be a rush job. I'm hoping to have it up by Sunday or Monday and we should still make it on time. I plan to merge the changesets tonight and then run compiles surreptitiously from the field as I pretend to read office E-mail.
I'm still doing planning for 18.0, our "Judgment Day" release. Because we will be shipping a new C++ runtime and other components, this will require more memory, and while 1GB RAM has been a practical minimum (he admits with obvious pain) for some time it will be the supported minimum with 18.0. It may still work on systems with less RAM, but it will definitely be impaired, and we won't accept bug reports on those systems. Assuming 17.0 will still build with gcc 4.0.1, it will be the last version to support 512MB machines. You are on notice. we'll see how it goes, based on Comments
More info when the 17 aurora port begins. For now, please try 15.0 and wait for 10.0.7 this weekend.
Job one is now to get to the next ESR, and I've decided we will skip 16 and go straight to 17-Aurora to ensure that we have enough cycles to get it working. After 15, there will be two or three 17 releases: definitely a 17 Aurora, maybe a 17 Beta, and then a 17-final which all stable users will be offered (so on the stable branch there will be 10.0.7, .8 and finally .9 to end our support of 10ESR). I will update the Roadmap with this information. Remember, builders, downstreamers and porters, even if we get 17 working with gcc 4.0.1, it will be the last version we support building with it (but assuming we do, it will be supported for the life of 17). More about that when I make a formal post about Judgment Day, which will occur when 18 hits Aurora.
