17.0.5 now available

Do give it a spin (release notes, downloads). I continue to be clearing out old alphas, betas and withdrawn releases, so get them as ye may. 17.0.5 will be finalized Monday night as usual. Watch for a new release next week.

AreWeScrewingTheTierThreePortsYet.com

First let me be the second or third? to welcome our SeaMonkey brethren to the JIT party; hikerxbiker &co. is now apparently implementing our methodjit in SeaMonkey via the AuroraFox changesets. However, if I may make a polite suggestion (especially given that Google Code is becoming a bit less welcoming to download-only projects), the project may wish to make changesets or source available, or at least build instructions on what to pull together to get things to work.

20 is going to be a little late, probably next week, because of a late-breaking JavaScript performance regression I finally tracked down which was due to bug 792108. This bug, in return for eliminating a odd execution path for document.all, stuck a stub call right in the middle of a methodjit fast path which caused V8 performance to drop nearly 15% and SunSpider to be 160% slower. I can understand the reasoning from the code cleanup perspective, but eliminating a major methodjit fast path to maintain what is essentially an Internet Explorer 4 holdover shim really sucks (and has no relevance in modern browsing since it only turns up in quirks mode).

Now, this is sort of my fault, because this "fix" (I use the term advisedly) was even back in the betas, but I was slack in the non-Dobbs way and only ensuring that the tests succeeded, not what the actual numbers were. However, you can see from AreWeFastYet that in early-mid December (ignore the actual numbers, just look at the trends) the red JM+TI line suddenly worsened (that's us) in SunSpider and V8, and most of the V8 regression seems to have been due to V8-Richards, which took a nose dive around the same time. This isn't of interest to Mozilla, because they built a fast path into IonMonkey (instead of the quick'n'dirty stub for JaegerMonkey) and the combined purple JM+TI+Ion line marches downwards apace since V8 mostly runs in Ion now, and for ports stuck on the interpreter the speed is probably not any more perceptibly glacial than it was before. It's only us weird arch ports like MIPS and SPARC that have only methodjit, and we're the only ones to get screwed. A heads up would have been nice instead of an opaque message about a minor change to the JSAPI in the technical newsgroup.

If this sounds familiar, that's because similar things happened in the twilight days before the end of TraceMonkey in Firefox 10, our original JIT. So I'm enlisting your help to look for major spikes like this in the future in case I miss them (or the day when the JM+TI line disappears completely). We should expect some minor performance erosion that's probably not worth the headache to fix, but a major hit like this is just not acceptable when our marquee feature is our JavaScript performance. The goal is to make it to Firefox 24 at any cost, even if we have to drag some old JS code with us.

As far as IonMonkey, I've actually made a bit of progress with it. By basing ourselves on the x86 backend -- which incredibly is cleaner than the perverse little ARM one -- I was able to use hints in their code to hopefully preserve all the hard work Ben did on our assembler, particularly his tinkering with G3/G4 and G5 branching for performance on specific processors. I need to do some work on the existing PowerPC assembler to add some new opcodes and Ion jump handling methods, but this is value-added work that shouldn't affect methodjit and will be silently part of 21. The Ion macro assembler, however, is not much like the methodjit macro assembler and will need to be written from scratch using the template in the x86 version. I'm still rather bearish on Ion because it does a lot of mucking around with stack frames, something PowerPC is not very good at, and it's questionable how much advantage it will take of our register set even though theoretically we can pump all 32 at it (but then we have to save those extra non-volatiles in every function prologue plus any non-volatile floating point registers, and that sucks, so we're not going to do that). I think I have all the pieces in js/src/ion/ppcosx; they just don't work or build, and much of the code isn't written (particularly the higher level abstract stuff which I don't even understand yet). The first order of business is just to get it to compile. Volunteers, as always, solicited. These pieces will be part of the 20 changesets when they become available, but if you want an early peek, just ask.

17.0.5 will fix websites using databases affected by issue 213 and should be out sometime this weekend or late Sunday, so watch for it then. 20 (also with that fix) will probably not be out until next weekend because I'm on a work trip in Sacramento, that wretched hive of scum and villainy known as the state capital, but we'll see if I can get some downtime between meetings. However, I want to do some basic compatibility testing on it prior to release to make sure our reverting the "fix" didn't cause some other unpleasant regression somewhere else, so I'll need to be at my desk first.

POSTSCRIPT. Looks like v8-crypto also took a spill, sometime between 17 and 19. This is only good for 5% on V8, and we already shipped this regression (so I'm not going to hold 20 for it if I can't figure it out right away), but if we fix it 20 should be able to clean the JavaScript performance floor with 17 and 19 which are already quite swift.

Goodbye, Google Code; hello, Sourceforge

No one is particularly happy about Google Reader being given the great shiv in the gut, but it also looks like we've outgrown Google Code. I've asked them for over a week and a half about upping our quota with no response, and since there's no paid tier on Google Code, there's no leverage. Self-hosting is not an option given that each release is downloaded over 20,000 times with binaries over 20MB apiece. I can't be angry about a free service declining to offer more space (though I can be irked that they're not responding to my request for a firm answer), but nevertheless the Mozilla rapid release system means we can't live within our current constraints for much longer and it's time to move on. Starting now, we will begin an orderly transition to our new home at Sourceforge, where it's not as snappy and fast as Google Code, but where there's no quota and no need to beg for more capacity.

The orderly transition will happen like this:

• The home page, blog and Tenderapp end-user support will remain at the same locations until there is a reason to change.
• This Saturday, 23 March, all aurora or beta releases (i.e., with an "a" or "b" in their version number) will be deleted from Google Code, along with all retracted releases. Changesets will remain; only the binaries will be expunged. This should buy us enough space to get to 24, the expected next ESR and stable release. If you want these binaries, you must grab them by Friday. The only exception will be 4.0b7 and b8, simply for nostalgia.
• All 17.x stable releases and unstable releases through 22 inclusive will still be uploaded to Google Code as usual, using the space freed up above. I'm pretty confident we'll make it to 24ESR, so I'm going to proceed with that assumption (if we turn out to drop parity sooner, substitute that version for "24" in what follows). Starting with 24 aurora and 24 beta, these releases will be uploaded to Sourceforge, and the expected 24ESR stable branch (and subsequent unstable releases) will be offered only from Sourceforge. The final release of 17 will also be on Sourceforge for posterity. Development on Google Code will cease completely at that time and all links to it will be removed.
• During the migration to 24ESR, all open issues will be reviewed for relevancy and likelihood of repair. Open issues judged irrelevant and/or unlikely to be fixed will be closed. Other open issues will be reopened at Sourceforge and relevant context transplanted if possible, and then closed on Google Code.
• Existing wiki release notes will remain at Google Code indefinitely until Google Code declines to maintain the project's files, whenever that is. At that time, they will become permanently unavailable as I don't see any reason to transfer these to the new project. However, currently maintained wiki entries such as the FAQ, build instructions, etc., will be rewritten on Sourceforge during the transition to 24ESR, and all release notes for 24+ will only be on Sourceforge.
• Remaining archived stable and unstable releases will remain at Google Code indefinitely until Google Code declines to maintain the project's files, whenever that is. At that time, I'll have to decide whether it's worth putting them somewhere else, but until then the files will remain available from there.

Classilla is nowhere near its cap, and Google Code is much friendlier to its browser core, so it will remain where it is; this only affects TenFourFox.

In other news, the 20 port is very nice. You'll get to play with it in a little under two weeks. Besides further improvements to graphics performance, plus WebRTC and user media, you'll also enjoy the new downloads interface which is now finally default and judged ready for primetime. Mozilla continues to concentrate on improving throughput and it's definitely paying off.

Anyway, I think this little experience with Google Code goes to show that everything is only worth what you pay for it. Watch for more news here as we meet transition milestones.

WebRTC comes to 10.4 (plus: Space, the increasingly limited frontier)

Say cheese!

WebRTC is an emerging, "bipartisan" standard allowing browsers to implement real-time communications ("RTC") in JavaScript with a standardized protocol. By bipartisan I mean Google (via Chrome) and Mozilla (via Firefox), but Opera (via whatever) is also part of that discussion. The Gecko derivatives such as us and AuroraFox are the first browsers to offer this to Power Mac users; I'm not aware of any other OS X PPC-compatible browsers that have implemented it.

To be frank, WebRTC per se has limited utility. While Fx20 has even better graphics improvement than 19, the low-hanging fruit is finally being plucked and graphics stack gains are likely to be less improved in 20 and 21. While audio-only communications should be possible on most G4s and maybe even upper-range G3s, full video and audio communication is likely only going to be satisfactory on high-spec multi-core G5 systems. The WebRTC library is massive, touching large amounts of browser code, and it required a lot of hacking to even build on 10.4. In fact, we are taking advantage of a minor Mozilla oversight: even though the default build uses a QTKit-based video capture system, and 10.4 should have QTKit, too many things don't work in 10.4's implementation and what does work in it does not properly mesh with the Objective-C support in gcc 4.6.3. But Mozilla also ported over the QuickTime 7 backend even though they themselves do not use it. This works nearly perfectly with 10.4; my iSight FireWire camera generated the image displayed, and theoretically any device that can be recorded by QuickTime is compatible with TenFourFox's implementation (however, my FireWire Orange Micro iBOT camera makes a scrambled image and I'm not sure what the difference is). If Mozilla or Google change the code so that the QuickTime backend doesn't work or is removed, then our WebRTC support might be shot. So far I've only tested the media capture components. It's entirely possible the networking section doesn't work right on 10.4 and I don't have a good way yet of testing this on my internal network.

So if it's so tenuous, and works fully only on a subset of Power Macs, and may one day not work at all, why put a lot of effort into it? The reason is simple: even though WebRTC is the best-known consumer, it's all part of a generic API called getUserMedia, which allows applications to capture video and audio for a whole range of functions. (Yes, audio works too, although there aren't a lot of examples that work properly with Firefox; most of them want Chrome. So much for standards.) For example, there's quite a few "photo booth" examples that let the browser capture an image and then work with it (submit it to imgur, save it to disk, you name it). The range of applications for even a simple feature like that should be obvious. Video display is run through QuickTime, meaning it can take advantage of all its little operating system cheats, and is AltiVec-accelerated on G4 and G5.

And, for you tinfoil hats, privacy is extremely rigid. The browser will make you verify when a page wants to get at your QuickTime video sources and let you pick the video and audio sources, which can be two different devices. If you refuse, nothing is sent. If you have no devices, nothing happens. I still need to do some polishing on the build system to make this work well, but I think it's good enough to unveil in 20. The interested can track progress in issue 214.

On the 17 front, a user discovered a serious bug in our IndexedDB support -- the compression library "Snappy" Mozilla started using between 10 and 17 never had its big-endian path turned on, causing corrupted tables and crashes on sites such as Kindle Cloud Reader. This bug affects all builds of Firefox on PowerPC and I upstreamed the fix in issue 213. It will be in 17.0.5 and 20.

That brings me to our second issue: we're running out of space in Google Code and although I filed a polite request for more quota (we're nearing our 4GB allotment), Google is balking at expanding our limit. We may need to delete some deprecated files and old betas (note: formal stable and unstable releases will never be deleted) to recover some of this capacity, or, look into a permanent solution if I'm not able to recover enough. We've never paid for the service, so I can't really be upset, but if Google decides they're not going to give us any more room we'll have to think of some other plan of action to keep things operating. While the wiki, issue tracker and build changesets would remain on Google Code for consistency no matter what, one option is to find (or, possibly, buy) off-site hosting for the binaries and/or try to start a mirror network. More hopefully next week when I get an up or down from Google Code's user support.

19.0.2 released

That's not a typo; there was no 19.0.1 desktop (it was a bugfix on mobile only). This fixes the Pwn2Own exploit and also includes the Safari bookmark fix as promised finally. To the downloads tab!

17.0.4 released

... and is available from the Downloads tab. This will go out later tonight assuming no problems along with the Finnish localization. Please try it out as soon as you can.

Chemspills for 17.0.4 and 19.0.x imminent

Batten down the hatches: those clever little sneaks at Pwn2Own broke open just about everything this year. Java got pwned twice (no surprise given our previous postings on the subject), and Firefox and Internet Explorer 10 fell too, as did Chrome through a very sophisticated attack that leveraged another bug in Windows to not only escape the Chrome sandbox but escalate privileges along the way. Eeek!

The flaw exploited in Firefox does affect TenFourFox and we will be issuing chemspills over the weekend for both stable and unstable branches to patch it. All major issues with 20 have been fixed; next is to issue fixes for some JavaScript conformance testing failures, some of which affect 17. These may or may not make it into the chemspill depending on how long it takes.

Amnesia at 20

The 20 port is operational, but there is at least one critical bug, namely that the browser is not remembering saved tabs. This appears to have been caused by converting session restore to off-the-main-thread in bug 532150. Part of the problem is that 10.4 has a bogus copyfile(3), but even using the provided (slower) JavaScript-based fallback copy operation it still doesn't save tabs. I haven't had a lot of luck figuring out why.

The other problem actually existed in 19 as well; if you resize a window to be larger, you might get a flash of black or garbage until the repaint driver wakes up and redraws the window. This is merely a nuisance really, but it looks ugly, so I'm thinking of how to force the resize event to invalidate immediately.

Intel 17.0.2 users affected by the freeze bug, recently confirmed by Claudio, may wish to watch issue 209. Again, no ETA -- it's unsupported, remember?

More this weekend when I'm back from my business trip.