31: close to beta (plus: new QTE and Mac|Life goes Low End)

Good news: there's going to be another stable release; 31 builds, links, gets off the ground and generally works. Yay! 24 will go into maintenance mode until 31 is ready for prime time, but the chance is better than even money that we'll have an on-time launch.

Between 29 and 31, Mozilla reworked the basic layers canvas code and this fixed the display problem with Google Maps and a lot of other sites. Plus, there don't appear to be any new regressions with the graphics code switching to Moz2D, and our "blue thumbnails" patch sticks fine in 31, so that's a lot of potential problems avoided and repaired.

The four major bugs we have left are all holdovers from 29, except this one: Google Maps does display correctly now, but it crashes with a null pointer assertion within the JavaScript virtual machine even with the JIT off. This looks like an endian problem introduced with bug 912456 or a related patch; simply wallpapering the assertion to make the browser continue doesn't cause any crashes, but Google Maps won't download new map content, so that's not very helpful. I consider this a showstopper. However, I also have a good idea where the problem is.

The second major bug is that the current version of the QuickTime Enabler does indeed hang up in TenFourFox 29+, as reported by a couple folks earlier. This is a problem with the old Add-on SDK jetpack version in v116, confirmed in that the MacTubes Enabler, which has a later jetpack, doesn't do this. Both of them will need a jetpack update for 31, but I updated the QTE jetpack and added a couple minor bug fixes and released that as QTE v120. You can get it from the QuickTime Enabler wiki page. It will work with 24 and 31 both, and then the QTE and MTE will be refreshed again after 31 is released. So that should be solved.

The two remaining issues are also 29 holdovers and while I consider them important to fix, I don't consider them showstoppers. It does look like editing keys have regressed per your reports, but not all keys have, so I'm not sure what's going on (menu keys and productivity shortcuts, for example, all function). This looks like our bug, but while I intend to fix it I don't consider this a shipping blocker for 31.0. Also, we still have the problem where webcam audio does not work (and neither does video-with-audio). However, our patch to force webcam video and video-without-audio does work, so the webcam can still be used for snapshots as its primary use case, and this is also shippable even if it's suboptimal.

31 also uses Mozilla's new generational garbage collector (GGC), which is even more aggressive about memory than the exact rooting GC in 29. The settings 29 use that we experimentally determined earlier in this blog are tuned for the older conservative garbage collector and may be counterproductive with GGC. I will likely change the time slice and some other parameters for 31 beta, so if you are using these custom GC settings please revert them before upgrading or the browser may not perform well.

Other than that, the browser appears to work fine and I think we're in good shape for another successful stable branch. Once I have the Google Maps problem fixed, I'll grab the beta source when 31 migrates from aurora and we should have a full-spectrum 31 beta release available a few days after the 24.6.0 update. Speaking of, 24.6.0 will be a security update only; there are no bugs on our side that will land, and I am not likely to do further feature work on 24 as the switchover to 31ESR approaches.

By the way, if you've got a newsstand nearby, you might want to pick up the current (June 2014) issue of Mac|Life and their article on rejuvenating your old Mac:

Even though it's a relatively basic article and their tips won't be big news to most of this blog's denizens, it's nice to see classic Macs still getting coverage in major Mac publications, and they even have a little section on Linux and alternative operating systems. Thanks to @thedoctor on App.net for spotting their shouts-out to TenFourFox and Classilla -- that's how you know you've arrived.

Not MIA, just BUSY

I'm still fighting with the server firmware to get uppsala's second core (which I paid good money for) turned back on, but in the meantime 31 is coming along; the patches are down and JavaScript at least builds and passes tests with the new generational garbage collector. However, changes made to accommodate the MIPS port and some other tweaks have degraded our JIT performance, so I need to pump that back up before continuing. Then we'll continue with the rest of the browser.

At the same time I'm looking ahead to see how feasible the ascent to 38ESR will be. Even money says that Mozilla and Google drop 10.6 support (and quite possibly 10.7 support) sometime in 2015, but if we can stall them to drop it for 38 but not remove any of the code like they did for 16-17 when 10.5 support was removed then we can probably make it. At that point we would exit the 38ESR support cycle in late 2016 when the youngest Power Mac will be turning 10 years old. If we have to drop source parity then, it would certainly not be in shame.

For JavaScript in Fx32 Mozilla has implemented irregexp, V8's regular expression engine, and dumped WebKit's YARR which was dragging down benchmarks. I was initially very worried we would need to implement yet a third JIT ourselves, but to my great delight it looks like Mozilla's adaptation uses the existing macroassemblers, so we just need to make sure there are no endian problems in it.

And more good news, this time for Linux/ppc users; at last there's apparently a solution to the infamous bug 961488. If it works, we'll see if it can be uplifted so you won't be out of commission for too long.

And we're back

Thanks for your patience. Other than a missing core which the vendor should be able to activate remotely, uppsala is back in service and everything should be pretty much back to normal. I am relieved to note that despite the need to wipe the RAID cache, no data appears to have been lost. One wonders when Apple will finally go to a "big boy" filesystem like AIX's JFS/JFS2, which has never let me down in two decades, as opposed to HFS+ which can poop its pants on a bad day.

System downtime update

The news has gone from bad to worse; it looks like uppsala, the big POWER6 that powers Floodgap, actually blew its mainboard and unfortunately the RAID array might have gone with it. A new mainboard should arrive today or tomorrow and we'll try to assess the disk damage when I get it installed (total repair bill so far $1700). If we're lucky, it's just the write cache and there weren't critical sectors in it, and the filesystems will be sane or at least somewhat recoverable. If we're not, we're starting from scratch and I'll have to rebuild the server; most of the data is backed up, but it's going to take some time. Either way, stockholm's going to be staying on active duty for at least a couple days more. Thanks for your patience.

Floodgap service note: emergency service reduction until further notice

Instead of working more on TenFourFox 31 aurora, I spent the evening putting stockholm, my trusty Apple Network Server 500, back in service; uppsala, the big POWER6, threw a rod sometime this afternoon and won't pass power-on diagnostics. Fortunately it had done its normal automated backups earlier, so there will be minimal data loss and the hard disks should still be okay. Let's hope it's something easy and cheap(er) to replace, like the RAID controllers or the accessory Ethernet, instead of replacing the entire system backplane which is basically an insanely expensive motherboard swap.

However, the ANS is just a little 604e with only 512MB of RAM and is not up to the task of serving everything the POWER6 does. I've restored static images of the TenFourFox, Classilla, HTTPi, Texapp and TTYtter sites and some utility areas along with the update XML files so that checking versions will work, and ordinary users won't notice much difference except that the site will be a little slower than usual. However, there are no gopher services and most of the rest of the website is down; really stockholm is just here to serve critical pages and collect E-mail until repairs are complete. That said, I'm glad I kept it configured as a server for just this sort of situation, and it's nice to have the old beast slip right back in to keep things running.

Hopefully my rep can overnight me the parts and we can get this fixed by Tuesday or Wednesday of next week.

Oh, you big lug, have some Australis. You deserve it.

Why should only people with Intel Macs enjoy the new shiny? You deserve some Australis too, even if it's only mostly-working Australis. So let's kick off our first official unstable release post-24 -- it's been a long time coming.

Since Mozilla is making some more substantial code changes between 29 and 31 (more on that in a minute), it's not really profitable to spend time fixing code that's likely just to get broken all over again, and I really want some test coverage on 10.5 systems since they are the majority of TenFourFox users despite the browser's focus. That means you get to play with Australis as well. We support almost all of the features of "real" Australis, including the hamburger menu, swoopy tabs and the secret unicorn. If you turn the title bar on, which I finally had to do because I miss the title bar, it's now very workable. I don't hate it. I don't love it, but I don't hate it. If you don't hate it either, my work here is done.

Please note there is only a 7450 and G5 build, mostly because this is intended for 10.5 testing; if you have a 7400 system, you can of course run the 7450 build with a mild penalty. G3 owners, you'll get some love on the next unstable cycle.

29 is, as mentioned, somewhat faster overall than 24. The big reason for this is Mozilla's continued conversion towards Azure, their lighter-than-Thebes-over-Cairo graphics architecture, which is now called Moz2D. For example, compositing is a lot faster because there's a lot less slinging of layers and interconversion, so pages can scroll faster (further helped by the delayed decoding of off-screen images in this version) and animation is smoother. Plus, with Off-Main-Thread Compositing (OMTC), the compositing will occur on a background thread, which performs very well on dual CPUs and of course the Quad which can schedule the work on another core. It also implements an improvement to garbage collection called exact rooting, which is a bit faster by itself, but will improve even more when true generational garbage collection comes to TenFourFox in 31. Finally, I added our own tweaks to reduce the GC load and improve the incremental garbage collection timeslice discussed in previous entries, and also rescheduled the PowerPC OS X xptcall assembly language code for better SPR usage, especially on G5.

Unfortunately, the Moz2D change also introduced several bugs ranging from minor to major severity -- as mentioned, our biggest problem is that canvases stay static. This does not affect many sites, but the sites it does affect tend to be high-profile and the bug is very noticeable on them because major portions of the page simply don't draw (such as the new Google Maps). All the Tier-1 ports support some manner of hardware acceleration and IPC and we don't; our canvas problem is a failure in basic layers used where no acceleration is possible. Although the bug is probably Mozilla's, we're probably going to be the ones who have to fix it because really only oddball Tier-3 ports like us excessively depend on basic layer compositing. Also, since the browser now preferentially deals in native-ordered graphics surfaces, and all the Tier-1 ports are little-endian, we'll likely encounter many endian issues with slinging bitmaps around (the SVG filters problem and the "blue" canvas snapshots were two of these I've corrected for 29 but may need to be revisited/re-repaired in 31). Sadly, Linux/PPC isn't likely to fix these first because they're still out of commission due to bug 961488, and the Moz2D code is changing so dramatically that I'm just going to start over with a 31 aurora and try to fix that rather than fix something (29) that's just going to change again. Since 24 doesn't end support until 31.2, I have 31a, 31b, 31.0 and 31.1 to get it right.

The other bug is that we still don't support audio or video-with-audio correctly in getUserMedia after the most recent update to WebRTC, but this is not a showstopper and will not delay release; video-without-audio works fine for things such as snapshots anyway, which is the most common use case right now. The problem seems due to an audio service thread that's prematurely dying off, so it should be fixable once I figure out what's killing it.

For this test, I am mostly interested in display failures in the default chrome (i.e., the part of the browser that isn't the web page), using the default theme. TenFourFox Australis should look mostly like the native one in Firefox 10.6+ with the major difference being we flat-shade most of the chrome for performance and visual continuity reasons, and we are still using the intermediate shade of grey for active windows we've used since TenFourFox 8. Otherwise, there shouldn't be much difference in the native Mac theme, if any. (Issue 247 still occurs with Personas, but this already affected 24 so it's not really a regression, and no one seems to be complaining about it since the window controls can be hovered and still work.)

The traffic light buttons should look proper on 10.5, should be shifted down to meet the tabs in the default window configuration, and the window widgets should all act as you expect them to. If you turn the titlebar back on, then it should "just work" and the traffic light buttons should go back to their usual location. There is a trivial issue where when the window animates, the traffic light buttons briefly don't repaint, but they do come back and I don't consider this worth fixing right now. I see no reason why this code should behave differently on Leopard, but if what you end up seeing looks wrong to you, please please please check it against the screenshots for 10.6 before filing a report -- I have a lot of work to get through to get 31 off the ground and trivially refutable reports slow me down. But if it really does look wrong, take a screenshot -- uncompressed TIFF or minimally compressed PNG, cropped to the offending area so we don't run out of attachment quota -- and post it to issue 267 with an explanation. It needs to be uncompressed because I may use your screenshot to take pixel measurements, so please do not post JPEGs.

If you notice rendering defects in web content, however, make sure it is not an HTML5 canvas first (right-click and select Inspect Element). If it's a canvas, please don't spam me with more reports; I don't need any more test cases, I've got plenty. If it's not, please verify it against Firefox 29 on 10.6+, Linux/Linux PPC or Windows, and file appropriately on Google Code if the bug is only in TenFourFox, just as you should be doing ordinarily.

You might want to use the Profile Manager to create a special 29-only profile until I think it's ready to completely replace 24.5.0. Right now, it isn't really, even though it's very close. Download from SourceForge.

As soon as I'm done with my final exam for this class, I'll start on 31 aurora, and we'll climb the summit again for another year of TenFourFox support. We're gonna make it! We're gonna make it!

24.5.0 released

24.5.0 is available for testing (download, release notes). It includes the fix for issue 265. Assuming no problems, it will become release on Monday night Pacific like usual.

I managed to figure out the "blue" thumbnails problem in 29. The only remaining moderate severity bugs are that Google Maps (the new one) still doesn't work properly, though old Google Maps does, and neither does audio or video-plus-audio in getUserMedia. The Google Maps problem seems related to canvas issues -- it does work, albeit glacially slowly, in 24, as do these animated canvas demos which don't work in 29 (only one frame is shown). I may still make a release regardless since we still need to test the widget changes against 10.5. While the webcam issue does not need to be solved before the launch of 31.0, the canvas problem does.

Unfortunately, PowerPC Linux users, it does not look like there's going to be a Firefox 29 for you or any of the *BSDs because of bug 961488. I can certainly look at it but it's going to be a while before I do. If you have the ability, please help debug what's going on -- keeping TenFourFox up, plus my day job and a Master's degree, has me very strapped for free cycles lately.