29 has officially moved into Aurora, the first version of what (we assume) will become the Australis Firefox. There are several bugs still pending related to OS X, and once those are fixed on Aurora, then we will try porting and God help us. For now I am taking a break from JavaScript work to do other things, such as my memorial to the old
floodgap.com server, the
Apple Network Server 500 and 700.
For 24.3.0 we made an apparently minor change to the user agent string by moving the TenFourFox token into middle position to stop Chase banking services from complaining users weren't using a supported browser. That worked, and instead broke Yahoo! Mail. So no more user agent changes and this one will be backed out for 24.4.0. Users who are bitten by this can use any of the user agent changer add-ons for now. The TenFourFox token must appear because we use it for detection purposes internally, and also because, believe it or not, some sites actually check for us and serve appropriate non-plugin content. Eventually when we drop source parity there will be a user agent pane in Preferences like Classilla has, but I'd rather users used an existing add-on while we still mirror ESR24.
For some time an annoyance has been that TenFourFox gets slower with prolonged use. Prolonged use means days to weeks, of course, but for those of us who never have crashes, the browser may only be restarted when there is an update to install. The reason for this is garbage collection: as more tabs are loaded and more pages are in use -- and recall that tabs keep a certain amount of in-memory cache for fast backup and forward -- the browser must visit these objects and determine if they are still referenced by something, and keep or dispose of them appropriately. This isn't a memory leak; it's just more stuff hanging around so that it can be referenced at will. We just need to manage it better.
Prior to Firefox 16/TenFourFox 17, garbage collection was an all-or-nothing phenomenon. It would occur (with a noticeable stall) and then keep going. In 16/17, Mozilla changed garbage collection to be incremental: the browser would divide garbage collection into time slices (default, 10ms) and execute those. If you can be reasonably certain enough work can occur in that timeslice so that the browser stays ahead of the problem, then this is fine, and makes the browser appear to garbage collect instantaneously on a modern system. Well, we're not modern systems, and arguably the 10ms time slice wasn't doing any significant garbage collection even on the G5, meaning it all slowly stacked up and the browser just scheduled garbage collection slices, over and over, forever.
For 24, I increased this time slice to 30ms. That helped by getting more done per slice, but eventually garbage still builds up and the browser gets into that vicious cycle again. There are two ways around this: make the time slice redonkulous, like 100ms, or turn off incremental garbage collection altogether and go back to the old periodic stop-the-world GC that would at least enable the browser to catch up even if now and then it will seize. Right now I'm testing option 2, and that's not doing too bad so far; my worry with option 1 is that if that cycle of GC after GC crops up again, then the slices it schedules are really long, and the browser gets starved for time to service user requests.
If you want to try this, you can, but if you screw this up you will significantly impact browser performance. Don't do this if you're not prepared for the consequences. For option 1, increase the value of javascript.options.mem.gc_incremental_slice_ms. For option 2, turn javascript.options.mem.gc_incremental off. Option 2, of course, overrides anything you have for option 1. Restart the browser to start from a clean slate. The browser will appear faster, of course, when you do; the real test is how it performs after a few days. If you don't know what these settings are or where you find them, you should not do this! I might consider adding this to the next unstable build based on people's opinions, but this is too risky a change for 24.
For those of you who are more risk-averse, remember that TenFourFox by default restores your tabs when the browser restarts, so if you restart the browser, all the tabs get unloaded and there are many fewer objects for the garbage collector to check (but they load when you access them). So, you can get the speed back with a quick restart add-on, and there is such an add-on available that adds a "Restart" hot key (Option-Command-R, or go to File and Restart), which amusingly doesn't require you to restart the browser to install. If this works well for folks, we'll make it an official recommendation. You can get Restartless Restart from Mozilla Add-ons.
In other news, Mozilla has officially removed all OS/2 code from the Firefox tree, finally ending that platform's support even as Tier-3. There have been problems with OS/2 support as far back as Firefox 3.6 and OS/2 support never officially made the jump to ESR17 even though there is a porting effort that did release a few beta builds. This doesn't mean there won't be another OS/2 Firefox, but it does mean that, like us, they'll have to take and port forward a lot of the pre-existing code, and it will require significantly more work for them because OS/2 is so unlike anything else. We ourselves remain a Tier-3 platform, but even if Mozilla took all the PowerPC OS X code out we would simply add it back in (and say mean things about them in this blog and make empty threats towards their pets and families), so this is more of a sad footnote than an actual change in service level.
So that's sad, but the hopeful part is that there is someone working on a MIPS port of IonMonkey and, surprisingly, asm.js/OdinMonkey. This is for mobile devices running MIPS, of course, so it's little-endian MIPS, but it is already making significant progress and we might be able to pattern our PowerPC port of IonMonkey off it. (I remain unconvinced of the utility of asm.js on big-endian platforms, given that all the extant asm.js code is little-endian and particularly the voluminous crapola code generated by Emscripten. We could make it byte-swap, maybe, but that would require two somewhat separate code generators and be a fabulous pain in the ass to manage.) I intend to watch their progress closely.
Finally, today's web hissy fit is about the possibility Mozilla may allow sponsored content on the new tab page. Sponsored tiles would be marked. That's about all we know; we don't know if third-party builds like us can (or will be forced to) also take part, we don't know what information the browser would collect, and we don't know how configurable it is (like whether it will always take up a certain number of tiles, or gradually disappear as the browser accumulates history, or how you can change that). The move does make some financial sense; Mozilla is too dependent on Google for income, and it needs to diversify its revenue stream to stay afloat. Furthermore, as a practical matter I'm not going to dismiss the idea immediately out of hand, because maintaining Floodgap is expensive and TenFourFox consumes a lot of my time, and while I have assiduously refused actual donations I obviously do accept ad revenue from this blog. If we got a cut, users could turn it off, and the information it collected was not personally offensive or overly intrusive, I would consider it. If we don't get a cut, I find it to be insufficiently configurable, or I conclude it collects an unacceptable amount of personal data, we would disable it at the code level. The whole idea is very embryonic. Either way you'll hear about it here.
