You can do what you wanna do / in ICC version 4 living colour management profiles

The 22 port is complete. If people want changesets, I can offer an early set; I'm now working in an optimized G5 build, and the browser seems to work fine.

The biggest change in this release is dropping Growl support for Mozilla XUL notifications. They work very well in 10.4, and web pages can (with your permission) trigger them too. Please note that my plan was always to support XUL notifications when they came along; they're much more flexible and integrated than Growl notifications. Image decoding has also been tuned to reduce memory overhead in this release, and image decoding can occur on multiple threads for people on multiprocessor G4 and G5 systems.

A user issue report is the impetus for issue 225, in which we will change the browser to accept ICC v4 profiles by default for colour management (not all v4 features are supported, but the profiles will at least work instead of falling back to sRGB which is usually amazingly wrong). If you are on 21, you can try this now by changing gfx.color_management.enablev4 to true and restarting the browser. Test before and after with this colour management test page. I would particularly like to make sure this works fine for 10.5. 17 users, you can try this too, but there is a bug with colour management on greyscale images such as xkcd, so you may wish to disable it after you've finished playing with it a bit; this fix will be added to 17.0.7. I plan to make this pref switch for 22.0 and 17.0.7 assuming there are no objections.

Some good news for a change. Most of the JavaScript test failures are actually attributable to the test harness -- if I run it in segments instead of "great big fricking ball of tests," it completes them as well as it has been previously completing them, at least. I suspect Python is doing something wrong here or maybe I'm just overloading the G5, since the test system will now cheerfully peg all your cores at 100% CPU if you let it. There is one new test failure which is indeed in asm.js and that is because -- surprise surprise -- it assumes a little-endian architecture. Not much we can do about that right now. Overall, however, 22 does apparently suffice as a worst-case drop-parity branch, much to my relief, and right away I'm going to start logging security fixes that need to land on it just in case that eventuality occurs.