Firefox 3.6 now disappears into the great Mercurial repo in the sky, its angel wings flapping slightly in the breeze. Mozilla 1.9.2 lives on for the moment in some separately-maintained third party builds and in Camino, but tomorrow there will be no more Fx3.6 and no more official Mozilla support for OS X PowerPC.
On that note, 10.0.4 is now in the release channel and advertised to users. PowerPC forever.
Monday, April 23, 2012
Saturday, April 21, 2012
10.0.4 released
Normally I would be at some fancy event with gorgeous blondes hanging off both arms and one or two attached to each foot regaling the crowd with my newest Theory of Everything, but you get bored doing that several times a day, so I built 10.0.4 instead now that Mozilla has finally seen fit to tag the branch. One of the changes Mozilla dropped busted the build, so that is fixed in the changesets. Please test it out before resuming your use of 12.
Speaking of 12, the failure on Acid3 is due to issue 146, which is an endian problem in the Open Type Sanitizer introduced by Mozilla bug 712217. It affects most downloadable fonts, in fact; you could get around it by disabling the OTS in about:config but I would really discourage that since the OTS is there to protect you from malicious or iffy fonts. The fix is pretty straightforward and I will push it upstream since it probably also affects SPARC. If I respin 12 it will be in there, otherwise 13. It does not affect 10.0.x.
Release notes and architectures:
Speaking of 12, the failure on Acid3 is due to issue 146, which is an endian problem in the Open Type Sanitizer introduced by Mozilla bug 712217. It affects most downloadable fonts, in fact; you could get around it by disabling the OTS in about:config but I would really discourage that since the OTS is there to protect you from malicious or iffy fonts. The fix is pretty straightforward and I will push it upstream since it probably also affects SPARC. If I respin 12 it will be in there, otherwise 13. It does not affect 10.0.x.
Release notes and architectures:
Friday, April 20, 2012
12.0 available (10.0.4 to follow)
I don't know what's going on with ESR 10.0.4 (there is no tagged build as of this writing), but 12 is signed off and has build tags, so we're shipping. I will build ESR 10 tomorrow regardless of whether there are build tags or not because we need to get basic testing by you, the basic testing basic audience, basically before we basically ship.
As promised, TenFourFox 12 contains a CoreGraphics backend to Azure, the 2D API Mozilla is developing to improve graphics performance. Azure right now is only used for canvas elements, but this is in more places than you'd think (for example, pdf.js, the JavaScript PDF reader, uses canvas and this backend is noticeably faster), so the improvement is more than you might suspect. The shipped backend with regular Firefox requires features of 10.5, but fortunately most of the features have undocumented private API versions in 10.4, particularly the compositing operators, so the port was relatively straightforward in that respect. It also relies on CGGradient, which is a CoreGraphics convenience interface to CGShading that was introduced in 10.5; we use Chad Weider's public domain CTGradient object instead to act as a gradient-style veneer over CGShading and then a custom Objective-C++ glue object to connect Mozilla's C++ interface to CTGradient's Objective-C interface. Finally, the regular Fx backend uses CGContextShowGlyphsAtPositions to display text, which is not in 10.4's CoreGraphics or private CoreText, so we just use a loop and good old CGContextShowGlyphsAtPoint (CGContextShowGlyphsWithAdvances is not suitable for a variety of reasons, not least being std::vector doesn't act quite right in 10.4). The only leftover bug on our part is a strange edge case with gradients where a terminal alpha-only stop can leave a strange dark fringe and I suspect this is actually a bug in CTGradient.
You will notice one particular difference between Cairo-based canvas and Azure CG canvas, depending on the fonts you have installed and their supported faces. If your Helvetica, say, lacks an italic, then if you ask for italic in that font you'll just get roman, whereas Cairo would try to simulate it. Strictly speaking I think CG has the correct behaviour here, and actually the CG backend works better with weird fonts in pdf.js as well that don't even display with Cairo.
Using CoreGraphics also introduces a modicum of hardware acceleration, which works on both 10.4 and 10.5. Stretching the canvas (such as in this GameBoy emulator when you press ESC) uses hardware to stretch it rather than software, and certain other CoreGraphics operations can also be accelerated by the graphics card. The proof is in the benchmarks. Not only compare TenFourFox 12 against 11, but try turning gfx.canvas.azure.enabled off and see what it does to your Peacekeeper scores. CoreGraphics accelerates these operations up to 60%. I can't wait for them to expand it to other components in the graphics stack, particularly SVG and HTML5 video blitting.
Other than that, 12 is a pretty blah release. There are some new CSS and DOM properties, but that's really it. Memory usage seems a bit worse due to a new font shape cache they are using, but this improves text-heavy pages, so it's hard to call it a bad tradeoff. The big changes in tab control and SPDY-by-default don't start appearing until Fx13.
In TenFourFox-specific news, this release improves XPCOM performance from JavaScript by simplifying the PowerPC assembly used for xptcall. It's a marginal win, but it's a win everywhere (issue 137). Java is also now disabled by default again, even if you have ignored my professional advice and turned on plugins, as reported by Chris (issue 141). This last fix will also occur in 10.0.4ESR stable, and the stable release will also have the blocklist disabled.
Release notes and architecture builds (watch for 10.0.4 probably tomorrow evening Pacific):
As promised, TenFourFox 12 contains a CoreGraphics backend to Azure, the 2D API Mozilla is developing to improve graphics performance. Azure right now is only used for canvas elements, but this is in more places than you'd think (for example, pdf.js, the JavaScript PDF reader, uses canvas and this backend is noticeably faster), so the improvement is more than you might suspect. The shipped backend with regular Firefox requires features of 10.5, but fortunately most of the features have undocumented private API versions in 10.4, particularly the compositing operators, so the port was relatively straightforward in that respect. It also relies on CGGradient, which is a CoreGraphics convenience interface to CGShading that was introduced in 10.5; we use Chad Weider's public domain CTGradient object instead to act as a gradient-style veneer over CGShading and then a custom Objective-C++ glue object to connect Mozilla's C++ interface to CTGradient's Objective-C interface. Finally, the regular Fx backend uses CGContextShowGlyphsAtPositions to display text, which is not in 10.4's CoreGraphics or private CoreText, so we just use a loop and good old CGContextShowGlyphsAtPoint (CGContextShowGlyphsWithAdvances is not suitable for a variety of reasons, not least being std::vector doesn't act quite right in 10.4). The only leftover bug on our part is a strange edge case with gradients where a terminal alpha-only stop can leave a strange dark fringe and I suspect this is actually a bug in CTGradient.
You will notice one particular difference between Cairo-based canvas and Azure CG canvas, depending on the fonts you have installed and their supported faces. If your Helvetica, say, lacks an italic, then if you ask for italic in that font you'll just get roman, whereas Cairo would try to simulate it. Strictly speaking I think CG has the correct behaviour here, and actually the CG backend works better with weird fonts in pdf.js as well that don't even display with Cairo.
Using CoreGraphics also introduces a modicum of hardware acceleration, which works on both 10.4 and 10.5. Stretching the canvas (such as in this GameBoy emulator when you press ESC) uses hardware to stretch it rather than software, and certain other CoreGraphics operations can also be accelerated by the graphics card. The proof is in the benchmarks. Not only compare TenFourFox 12 against 11, but try turning gfx.canvas.azure.enabled off and see what it does to your Peacekeeper scores. CoreGraphics accelerates these operations up to 60%. I can't wait for them to expand it to other components in the graphics stack, particularly SVG and HTML5 video blitting.
Other than that, 12 is a pretty blah release. There are some new CSS and DOM properties, but that's really it. Memory usage seems a bit worse due to a new font shape cache they are using, but this improves text-heavy pages, so it's hard to call it a bad tradeoff. The big changes in tab control and SPDY-by-default don't start appearing until Fx13.
In TenFourFox-specific news, this release improves XPCOM performance from JavaScript by simplifying the PowerPC assembly used for xptcall. It's a marginal win, but it's a win everywhere (issue 137). Java is also now disabled by default again, even if you have ignored my professional advice and turned on plugins, as reported by Chris (issue 141). This last fix will also occur in 10.0.4ESR stable, and the stable release will also have the blocklist disabled.
Release notes and architecture builds (watch for 10.0.4 probably tomorrow evening Pacific):
Wednesday, April 4, 2012
Poisoned coffee
The Flashback trojan which is making the rounds can mount an attack through the vulnerable JVMs in 10.4 and 10.5 (and as we all know, Apple is no longer issuing security updates for PowerPC at all). I don't know if Flashback can penetrate PPC systems or merely crashes them, but there are enough cross-platform components within the attack that it seems at minimum possible. (Note to Classilla users: the JVM is too old in OS 9 and the cross-platform components require a Unix shell, so the most Flashback can make you do is bomb.)
UPDATE: Some people are linking to this post to try to warn PowerPC users that we are also vulnerable, but I have seen many people express disbelief because to date no one knows of any PPC systems that have actually been infected.
Well, let me disabuse you of the notion we are resistant to the attack: the CVE in question exploited by Flashback a/k/a Flashfake is CVE-2012-0507 and Oracle themselves say Java 2 Standard Edition 5.0 update 33 and before are vulnerable. J2SE 5.0 corresponds to Java VM 1.5, which is the JVM in use on 10.4 and 10.5 PowerPC, and no version of Apple Java for 10.4 or 10.5 is at update 33. So the hole exists. (There is an OpenJDK 7 available for 10.5 at least, but there is no browser plugin for it and the vulnerable JVM is still on your system, so you must take specific steps to disable the old system VM and also disable Java in your browser.)
But wait, it gets worse. The hole in question is a "sandbox violation" meaning it allows Java code that would normally run in an unprivileged environment to run with privileges. Read that sentence again: it allows Java code to do it, not merely native code. The malicious bootloader which Flashback/Flashfake uses to mount its attack will run on PowerPC because it is written in Java. When Flashback/Flashfake starts up, it initiates the sandbox exploit and, now possessing privileges, runs its bootloader which then grabs an actual native binary. The bootloader is crossplatform and works on Windows and Mac OS X. The binary the bootloader fetches and then executes is the true payload. MSDN has an excellent analysis.
The true (and as near as I can tell, the only) reason Power Macs are resistant so far is because the binary that is loaded is not compiled for PPC. That's it. The actual attack works. If the evil brains in a .jar behind Flashback were to compile their payload as a Universal binary and link it to an appropriate PPC SDK, the payload would also run, and the system would be exploited. So turn off Java now. It is no longer safe on Power Macs. Don't make your system's safety dependent on how lazy the Flashback authors are.
Back to the previous article ...
Java requires a (surprise!) plugin to run in TenFourFox, so by default we are not vulnerable, and even if you enable plugins "against medical advice" the Java plugin preference is specifically set to hide the Java plugin by default as well. You would have to turn on both preferences to actually get the exploit to occur (assuming that it can attack Power Macs), so we are safe from this attack in the vast majority of configurations.
Mozilla has started blocking old versions of the Java Plugin on Windows because of the BlackHole exploit kit which takes advantage of the same vulnerability, and they will extend this block to the Mac shortly. I don't know if we will take this code since it will block everyone from using Java, even those taking reasonable precautions, because there is no way to update the system JVM. It might be nice for someone in their copious spare time to look at porting one of the Java SDK clones to 10.4, you know, between saving the world and doing the dishes.
The CoreGraphics accelerated backend I talked about in the last post is now able to partially render text too. Still get crashes with gradients, so still not ready for primetime.
UPDATE: Some people are linking to this post to try to warn PowerPC users that we are also vulnerable, but I have seen many people express disbelief because to date no one knows of any PPC systems that have actually been infected.
Well, let me disabuse you of the notion we are resistant to the attack: the CVE in question exploited by Flashback a/k/a Flashfake is CVE-2012-0507 and Oracle themselves say Java 2 Standard Edition 5.0 update 33 and before are vulnerable. J2SE 5.0 corresponds to Java VM 1.5, which is the JVM in use on 10.4 and 10.5 PowerPC, and no version of Apple Java for 10.4 or 10.5 is at update 33. So the hole exists. (There is an OpenJDK 7 available for 10.5 at least, but there is no browser plugin for it and the vulnerable JVM is still on your system, so you must take specific steps to disable the old system VM and also disable Java in your browser.)
But wait, it gets worse. The hole in question is a "sandbox violation" meaning it allows Java code that would normally run in an unprivileged environment to run with privileges. Read that sentence again: it allows Java code to do it, not merely native code. The malicious bootloader which Flashback/Flashfake uses to mount its attack will run on PowerPC because it is written in Java. When Flashback/Flashfake starts up, it initiates the sandbox exploit and, now possessing privileges, runs its bootloader which then grabs an actual native binary. The bootloader is crossplatform and works on Windows and Mac OS X. The binary the bootloader fetches and then executes is the true payload. MSDN has an excellent analysis.
The true (and as near as I can tell, the only) reason Power Macs are resistant so far is because the binary that is loaded is not compiled for PPC. That's it. The actual attack works. If the evil brains in a .jar behind Flashback were to compile their payload as a Universal binary and link it to an appropriate PPC SDK, the payload would also run, and the system would be exploited. So turn off Java now. It is no longer safe on Power Macs. Don't make your system's safety dependent on how lazy the Flashback authors are.
Back to the previous article ...
Java requires a (surprise!) plugin to run in TenFourFox, so by default we are not vulnerable, and even if you enable plugins "against medical advice" the Java plugin preference is specifically set to hide the Java plugin by default as well. You would have to turn on both preferences to actually get the exploit to occur (assuming that it can attack Power Macs), so we are safe from this attack in the vast majority of configurations.
Mozilla has started blocking old versions of the Java Plugin on Windows because of the BlackHole exploit kit which takes advantage of the same vulnerability, and they will extend this block to the Mac shortly. I don't know if we will take this code since it will block everyone from using Java, even those taking reasonable precautions, because there is no way to update the system JVM. It might be nice for someone in their copious spare time to look at porting one of the Java SDK clones to 10.4, you know, between saving the world and doing the dishes.
The CoreGraphics accelerated backend I talked about in the last post is now able to partially render text too. Still get crashes with gradients, so still not ready for primetime.
Monday, April 2, 2012
TenFourBird files, into an Azure sky
Well, there's now TenFourBird builds available from our anonymous builder in the land of the Rising Sun. I don't use Thunderbird and in fact still read my mail on a shell account, but it does start up and appear to run normally on my G5, and (s)he offers all four architecture builds, so I'm interested how you Thunderbird users find it now that Thunderbird 3.1 is shortly to end with Fx3.6.
As mentioned, I have TenFourFox 12 up and running (this post is being made in it) and a first pass at the CoreGraphics canvas backend for Azure. The Azure project is Mozilla's attempt to reformulate their graphics stack, in the same way that they did with Cairo way back in Mozilla 1.8/Firefox 1.5. Prior to that Mozilla used various system APIs and gaps in support were sometimes evident from platform to platform, so Cairo came along and offered a stable, standardized way to generate similar graphic content on the supported platforms. Mozilla started with Cairo for HTML canvases in 1.8, and in 1.9/Firefox 3.0 Cairo ended up doing everything.
Cairo can be very fast, but because it is a mid-level API, it inserts a level of complexity and therefore extra code. More to the point, it does not exactly map to the underlying operating system and the conversions needed (and the internal state it needs to maintain) can be expensive to handle. For Quartz a/k/a CoreGraphics it ends up working through two levels of abstraction and this is especially painful to us because we render in software. While Cairo made a lot of code simpler, its drawbacks are now unfortunately apparent.
So Azure tries to map closer to the underlying API, which in our case is Quartz/CoreGraphics, and allows primitives and drawing operations that map more directly (in some cases 1 to 1) to the underlying operating system. This allows us to take advantage of whatever hardware acceleration is available to Quartz, but more importantly it lets us get around a lot of unnecessary bloat. This bloat is even worse than I thought: our current CoreGraphics backend in the forthcoming 10.4Fx 12 accelerates canvas performance by almost 60% on Peacekeeper. That is a smoking hot win. Eventually Mozilla wants to do as much of the browser as possible in Azure, just as they did with Cairo, with Cairo existing as a fallback or for printing.
That's the good news, anyway. The bad news is 1) it's only for canvases right now and 2) our backend doesn't fully work; text doesn't render in canvases yet and gradients make it randomly crash, so I still have some work to do. By default it ships disabled, but you can turn it on in about:config and I will tell you how when it is available. Even in this incomplete form it will still pass Peacekeeper and run a number of demos. Don't expect night and day speeds, but you will notice a difference.
Mozilla also did some improvements to JavaScript, which is particularly noticeable on G3 and G4 (G5 only modestly improves for some reason), and I have rescheduled XPT calls to system components from JavaScript to be faster on all platforms, not just G5. Overall the browser feels smoother, but I've only been using it for a couple days.
I have not yet heard when 10.0.4 will go to build, but there are a lot of fixes in it. I will make 12 available when the RC is signed off. In the meantime, post your TenFourBird comments; I'm curious how people who actually use an E-mail client will find it.
As mentioned, I have TenFourFox 12 up and running (this post is being made in it) and a first pass at the CoreGraphics canvas backend for Azure. The Azure project is Mozilla's attempt to reformulate their graphics stack, in the same way that they did with Cairo way back in Mozilla 1.8/Firefox 1.5. Prior to that Mozilla used various system APIs and gaps in support were sometimes evident from platform to platform, so Cairo came along and offered a stable, standardized way to generate similar graphic content on the supported platforms. Mozilla started with Cairo for HTML canvases in 1.8, and in 1.9/Firefox 3.0 Cairo ended up doing everything.
Cairo can be very fast, but because it is a mid-level API, it inserts a level of complexity and therefore extra code. More to the point, it does not exactly map to the underlying operating system and the conversions needed (and the internal state it needs to maintain) can be expensive to handle. For Quartz a/k/a CoreGraphics it ends up working through two levels of abstraction and this is especially painful to us because we render in software. While Cairo made a lot of code simpler, its drawbacks are now unfortunately apparent.
So Azure tries to map closer to the underlying API, which in our case is Quartz/CoreGraphics, and allows primitives and drawing operations that map more directly (in some cases 1 to 1) to the underlying operating system. This allows us to take advantage of whatever hardware acceleration is available to Quartz, but more importantly it lets us get around a lot of unnecessary bloat. This bloat is even worse than I thought: our current CoreGraphics backend in the forthcoming 10.4Fx 12 accelerates canvas performance by almost 60% on Peacekeeper. That is a smoking hot win. Eventually Mozilla wants to do as much of the browser as possible in Azure, just as they did with Cairo, with Cairo existing as a fallback or for printing.
That's the good news, anyway. The bad news is 1) it's only for canvases right now and 2) our backend doesn't fully work; text doesn't render in canvases yet and gradients make it randomly crash, so I still have some work to do. By default it ships disabled, but you can turn it on in about:config and I will tell you how when it is available. Even in this incomplete form it will still pass Peacekeeper and run a number of demos. Don't expect night and day speeds, but you will notice a difference.
Mozilla also did some improvements to JavaScript, which is particularly noticeable on G3 and G4 (G5 only modestly improves for some reason), and I have rescheduled XPT calls to system components from JavaScript to be faster on all platforms, not just G5. Overall the browser feels smoother, but I've only been using it for a couple days.
I have not yet heard when 10.0.4 will go to build, but there are a lot of fixes in it. I will make 12 available when the RC is signed off. In the meantime, post your TenFourBird comments; I'm curious how people who actually use an E-mail client will find it.
Subscribe to:
Posts (Atom)