We're tracking Mozilla's determination to disable the tracing JIT for JavaScript (bug 693815), which would count as a serious blow to us and would stop us updating to a later version if we weren't able to get the method JIT operational. JavaScript compilation is our biggest marquee feature and we absolutely have to have it functional. This bug has already landed for 10, but the switch-off itself is relatively trivial to back out. What won't be trivial is what will follow, because it will almost certainly break the tracer even if it is reenabled.
Methodjit, which is the JavaScript method compiler, is about 60% written, but this is just a first draft; it is in no way tested to even build, let alone function. It may force switching to a newer compiler at a minimum, though Tobias has already done this work and we are already on a different linker. However, what I'm more concerned about is that I won't have it either stable enough or fast enough by the time it will be our only choice as a compiler, causing regressions at best and wholesale loss of functionality at worst. Those of you who are longtime loyal users already know it took us until almost 7.0 to get most of the bugs worked out of our current tracer, and that was handed to us almost finished and already in use by Adobe (by the way, Adobe has accepted our finalized tracer into nanojit). This is being developed from scratch, is a much larger undertaking and is being forced to occur in significantly less time.
Job one and the best case is that we get the method compiler backend (this includes the assembler and the modifications to the method compiler for the PowerPC ABI) in time for 10 beta; I just don't see this happening in time for 9 and 10 is still iffy.
If we don't get this ready for 10 beta, the current outlook (which can still change, because 10 is the nightly) is that all that will land in 10 is disabling the tracer and investigating any regressions. This is pretty straightforward to undo, but it serves as a warning. Once it is accepted that the tracer will be disabled by Mozilla, then backlogged incompatible changes will start landing, and I hope they land in 11; if they don't, then we will either back them out or force a downgrade to a known working version, most likely the release from 9. We can only maintain this hybrid for so long, obviously, before it becomes incompatible with the JS API the browser requires. If we can't reasonably complete the methodjit and we fall behind, then we will drop to feature parity and source parity will end. Optimally we would like to conclude source parity on a release that coincides with a Long Term Support branch because we will then have the advantage of Mozilla security updates, but we can provide these ourselves if we don't get that fortunate.
If you know someone experienced with PowerPC assembly who would like to contribute, please advise. I'm pretty good with PPC machine code, but I'm no genius, Surely someone from Armonk reads this blog and has some copious free time?
Meanwhile, we are continuing on for 8. For final I have approved Tobias' improvement to the UTF8 to Unicode AltiVec converter that is noticeably faster, and because this is a frequently utilized function that everything calls, everything speeds up. For 9 we will add accelerating colour management and additional encoding methods with AltiVec. Even if JavaScript stalls, the rest of the browser core is advancing at a rapid pace. I expect Mozilla will declare the RC within one to two weeks, and you will get it shortly afterwards.
The QuickTime Enabler unfortunately will not be so timely. Mozilla's Add-On SDK group has stalled on 1.2, which is the SDK required for 8, so I have not been able to do more work on it. I do have some surprises in store and I hope to have this available very shortly when the Mozilla Add-On Builder supports the 1.2 SDK. And I thought that Jetpack add-ons were supposed to be insulated for this ... We'd have done better with a standard XUL extension! We may do this anyway when time comes to integrate QTE directly in to the browser, but we're not up to that point yet.
More soon.
Wednesday, October 19, 2011
Friday, October 7, 2011
8.0b1 available
TenFourFox 8 beta 1 is available, corresponding approximately to Firefox 8 beta 2. Fx8 is probably the first "major" update to Firefox since 4; the rest have been mostly merely incremental. Not that there haven't been important features introduced in 5, 6 and 7, of course, but 8 has some really nice new features. The one I really dig is the moveable tabs a la Chrome. Instead of grabbing tabs and having a hard-to-see placeholder mark your drop target, the tab moves with you. If you pull it out of the window, it turns into a thumbnail so that you know it will generate a new window on landing. It's really nice, and since it's really nice and awesome, it naturally may get turned off before release because it's apparently breaking some add-ons relying on the old tab behaviour. That would be a serious bummer and I hope it doesn't happen, because it's very elegantly implemented. It is also accompanied by smoother tab animation and the ability to load tabs on-demand when you start the browser instead of all at once. It's great work.
You're going to see the other major new feature immediately when you start the browser, and that is the new add-ons check panel. Each new version of Fx (and TenFourFox) will inventory your add-ons for you each time you update, allowing you to disable ones you don't need or forgot you had and see which ones won't make it. This is also a very welcome feature.
And, at the same time you experience the new check panel, you will see the major change we have introduced ourselves with this release: the end of appearance parity. Mozilla significantly rewrote large portions of the widget library with this release, requiring a large amount of code to be converted or reverted. Buttons looked wrong, the browser chrome was super dark and didn't match even Leopard's darker window style (and was totally bogus in Tiger), and some controls didn't even appear at all. But, unfortunately, this is expected; Mozilla dropped 10.4 compatibility and I am very surprised they are still maintaining 10.5 compatibility -- I expect that to end probably around the end of Fx3.6 -- so we should not suffer any illusions about the rug not getting pulled out from under us. With 8.0, by policy TenFourFox's interface will be at feature parity with Firefox, not appearance parity. You should still be able to do the same things with the interface, but colours and rendering may be different. We will eventually spin off the widget and theme ("Pinstripe") packages into separate Tiger widget and "Tigerstripe" themes to preserve compatibility and insulate us from sudden shocks and changes. This will probably be completed when Mozilla ends 10.5 support.
As a result, there were several appearance bugs that did not appear until late in testing and I have chosen to release the beta with them so that the rest of the changes can be banged on. Please don't report these, I already know that 1) there is no button frame on the buttons on the first-run add-on panel (I will probably just convert this to a regular Cocoa button) and 2) the Places/Bookmarks forward-back buttons have the rounded corners on the wrong edges. They will be fixed in the next beta and/or RC. I will also redo our easter egg because even though it is a long-time crowd pleaser going back to the Classilla 9.0 days, it is also probably rather tasteless in light of recent events. Charles Moore put it best: "I didn't always agree with Jobs, but where I didn't, I am obliged to concede that he was more often proved right, or at least reading market prospects and trends more accurately than I." RIP, Steve.
The lighter window chrome will startle some people. This is not a bug; it is on purpose. I never liked the darker chrome on Tiger and the code Mozilla added in 8 causes mismatches with the tab bar in 10.4, so I wrote new colour standards for Tiger to match standard window chrome and tested it on Leopard as well to make sure the colours are continuous. (Issue 16 still applies if you have the tab bar disabled.) This will be the new chrome for the time being, though I am considering emphasizing the tab edges to make them stand out more visually. When we fully split off Tigerstripe, I would love to have contributions (please, not merely "I want" suggestions: write the bloody code) for customizing our theme uniquely. If the Mozilla mountain won't come to Mohammed, then Mohammed is going off to Aruba to hang out with gorgeous co-eds. Your CSS can power those co-eds. And that was probably the worst metaphor I've ever written in this blog.
Oh, one other neat thing in Firefox 8 is HTML5 context menus. Right click on the animated image in this demonstration. I think this has loads of possibilities for application designers.
So that's the big overview, but wait, there's more! Tobias has written an interface to allow the browser to use ImageIO's AltiVec-accelerated JPEG decoder, which improves overall rendering of JPEG images on G4 and G5 by almost 125%. We scrubbed this for security issues in 10.4 and 10.5 and we can't find any; even if something does pop up, it's easy enough to switch back to the slower but safe in-tree JPEG library. We are only planning to do this for JPEG; PNG has known security vulnerabilities and isn't AltiVec-accelerated anyway. G3 users will use the regular JPEG library as before. Another beer for Tobias! Tobias has also submitted a very simple change to reduce the browser's CPU usage when it is in the background; it was continuing to receive mouse events unnecessarily and trying to process them, and issue 19 covered the circumstances where it actually needed them, so the code to receive the unneeded events was removed. Laptop users will particularly appreciate the battery impact. Please report any variances in activity.
We are also using minor tweaks to the AltiVec code introduced in 6 which increase performance marginally, and there is another change I need to land in the tracejit before RC/final to correct a small performance problem there too.
For those concerned about issue 84, the infamous table shift issue that plagues some pages in 6.0 and 7.0, there is a bandaid in 8.0 which fixes the reported sites and test-cases. The bug is due to an optimization problem and does not appear in unoptimized debug builds (by the way, for builders, debug builds are now fixed in 8.0 and should be working again). I still have not isolated the exact place where it occurs, so there is now a very grotesque parser patch that rewrites the page code to eliminate this specific issue. I tried to minimize side effects as much as possible and the parser bandaid will log occurrences to the Console to facilitate study. The patch does not appear yet in the changesets because I am hoping I won't have to ship with it, but if I do, it will be there and I will be sad.
Chris is continuing to work on our localization infrastructure and translators are wanted. Most of the Firefox strings apply, but slight changes are required for our few interface differences. If you are interested in the localization effort and/or working on the locale installer, as always, sign up in issue 42 and issue 61. Chris drinks his beer in several different languages.
The future of JavaScript is methodjit and I am continuing the conversion on an internal tree. This is the method compiler for JavaScript that Mozilla is shipping as JaegerMonkey and will use for the forthcoming IonMonkey. I am really pushing this as a priority because it also accelerates regular expression parsing; even though we successfully got bug 684559 accepted in the tree rather than contending with the sucky YARR regexp interpreter, we suck wind on SunSpider's regex testing and we can gain some big time back by precompiling them. My goal is to get the G5's SunSpider time under one second (right now it is approximately 1600ms on my quad 2.5GHz G5 in high power mode). I really want to have this ready for testing by 9 or 10. Watch for more announcements.
Some housekeeping. I have not heard any objections to running ads on this blog to allow me to recoup some of the hosting costs, so I will probably set that up. (You are free to AdBlock, of course.) Also, here is a little ranty bit, not for our normal blog denizens but for newcomers here with an axe to grind. I continue to receive letters ranging from petulant to nasty about TenFourFox and plugins from people who don't read the announcement on the main page, on the start page, or in the release notes. You don't pay me for this browser, you don't contribute to it, and you don't have to use it. Ignoring all else about plugins and PowerPC, if your life online entirely consists of Flash movies and Zynga games, get a new computer. There will never be a Flash 10.2 on PPC. There will never be another version of Flash on PPC, ever. This policy reflects that reality. Sending me E-mails on how you hate what I've "done to Firefox" makes you look entitled and selfish, and is a waste of your time and mine. The Apple store is over there. Do yourself a favour and buy a nice new mini, and don't use TenFourFox. Above all else, don't complain to me about it. Ranty bit over.
Anyway, that wasn't directed at you guys, the loyal supporters. You get the good stuff. Read the release notes, then grab for your architecture:
You're going to see the other major new feature immediately when you start the browser, and that is the new add-ons check panel. Each new version of Fx (and TenFourFox) will inventory your add-ons for you each time you update, allowing you to disable ones you don't need or forgot you had and see which ones won't make it. This is also a very welcome feature.
And, at the same time you experience the new check panel, you will see the major change we have introduced ourselves with this release: the end of appearance parity. Mozilla significantly rewrote large portions of the widget library with this release, requiring a large amount of code to be converted or reverted. Buttons looked wrong, the browser chrome was super dark and didn't match even Leopard's darker window style (and was totally bogus in Tiger), and some controls didn't even appear at all. But, unfortunately, this is expected; Mozilla dropped 10.4 compatibility and I am very surprised they are still maintaining 10.5 compatibility -- I expect that to end probably around the end of Fx3.6 -- so we should not suffer any illusions about the rug not getting pulled out from under us. With 8.0, by policy TenFourFox's interface will be at feature parity with Firefox, not appearance parity. You should still be able to do the same things with the interface, but colours and rendering may be different. We will eventually spin off the widget and theme ("Pinstripe") packages into separate Tiger widget and "Tigerstripe" themes to preserve compatibility and insulate us from sudden shocks and changes. This will probably be completed when Mozilla ends 10.5 support.
As a result, there were several appearance bugs that did not appear until late in testing and I have chosen to release the beta with them so that the rest of the changes can be banged on. Please don't report these, I already know that 1) there is no button frame on the buttons on the first-run add-on panel (I will probably just convert this to a regular Cocoa button) and 2) the Places/Bookmarks forward-back buttons have the rounded corners on the wrong edges. They will be fixed in the next beta and/or RC. I will also redo our easter egg because even though it is a long-time crowd pleaser going back to the Classilla 9.0 days, it is also probably rather tasteless in light of recent events. Charles Moore put it best: "I didn't always agree with Jobs, but where I didn't, I am obliged to concede that he was more often proved right, or at least reading market prospects and trends more accurately than I." RIP, Steve.
The lighter window chrome will startle some people. This is not a bug; it is on purpose. I never liked the darker chrome on Tiger and the code Mozilla added in 8 causes mismatches with the tab bar in 10.4, so I wrote new colour standards for Tiger to match standard window chrome and tested it on Leopard as well to make sure the colours are continuous. (Issue 16 still applies if you have the tab bar disabled.) This will be the new chrome for the time being, though I am considering emphasizing the tab edges to make them stand out more visually. When we fully split off Tigerstripe, I would love to have contributions (please, not merely "I want" suggestions: write the bloody code) for customizing our theme uniquely. If the Mozilla mountain won't come to Mohammed, then Mohammed is going off to Aruba to hang out with gorgeous co-eds. Your CSS can power those co-eds. And that was probably the worst metaphor I've ever written in this blog.
Oh, one other neat thing in Firefox 8 is HTML5 context menus. Right click on the animated image in this demonstration. I think this has loads of possibilities for application designers.
So that's the big overview, but wait, there's more! Tobias has written an interface to allow the browser to use ImageIO's AltiVec-accelerated JPEG decoder, which improves overall rendering of JPEG images on G4 and G5 by almost 125%. We scrubbed this for security issues in 10.4 and 10.5 and we can't find any; even if something does pop up, it's easy enough to switch back to the slower but safe in-tree JPEG library. We are only planning to do this for JPEG; PNG has known security vulnerabilities and isn't AltiVec-accelerated anyway. G3 users will use the regular JPEG library as before. Another beer for Tobias! Tobias has also submitted a very simple change to reduce the browser's CPU usage when it is in the background; it was continuing to receive mouse events unnecessarily and trying to process them, and issue 19 covered the circumstances where it actually needed them, so the code to receive the unneeded events was removed. Laptop users will particularly appreciate the battery impact. Please report any variances in activity.
We are also using minor tweaks to the AltiVec code introduced in 6 which increase performance marginally, and there is another change I need to land in the tracejit before RC/final to correct a small performance problem there too.
For those concerned about issue 84, the infamous table shift issue that plagues some pages in 6.0 and 7.0, there is a bandaid in 8.0 which fixes the reported sites and test-cases. The bug is due to an optimization problem and does not appear in unoptimized debug builds (by the way, for builders, debug builds are now fixed in 8.0 and should be working again). I still have not isolated the exact place where it occurs, so there is now a very grotesque parser patch that rewrites the page code to eliminate this specific issue. I tried to minimize side effects as much as possible and the parser bandaid will log occurrences to the Console to facilitate study. The patch does not appear yet in the changesets because I am hoping I won't have to ship with it, but if I do, it will be there and I will be sad.
Chris is continuing to work on our localization infrastructure and translators are wanted. Most of the Firefox strings apply, but slight changes are required for our few interface differences. If you are interested in the localization effort and/or working on the locale installer, as always, sign up in issue 42 and issue 61. Chris drinks his beer in several different languages.
The future of JavaScript is methodjit and I am continuing the conversion on an internal tree. This is the method compiler for JavaScript that Mozilla is shipping as JaegerMonkey and will use for the forthcoming IonMonkey. I am really pushing this as a priority because it also accelerates regular expression parsing; even though we successfully got bug 684559 accepted in the tree rather than contending with the sucky YARR regexp interpreter, we suck wind on SunSpider's regex testing and we can gain some big time back by precompiling them. My goal is to get the G5's SunSpider time under one second (right now it is approximately 1600ms on my quad 2.5GHz G5 in high power mode). I really want to have this ready for testing by 9 or 10. Watch for more announcements.
Some housekeeping. I have not heard any objections to running ads on this blog to allow me to recoup some of the hosting costs, so I will probably set that up. (You are free to AdBlock, of course.) Also, here is a little ranty bit, not for our normal blog denizens but for newcomers here with an axe to grind. I continue to receive letters ranging from petulant to nasty about TenFourFox and plugins from people who don't read the announcement on the main page, on the start page, or in the release notes. You don't pay me for this browser, you don't contribute to it, and you don't have to use it. Ignoring all else about plugins and PowerPC, if your life online entirely consists of Flash movies and Zynga games, get a new computer. There will never be a Flash 10.2 on PPC. There will never be another version of Flash on PPC, ever. This policy reflects that reality. Sending me E-mails on how you hate what I've "done to Firefox" makes you look entitled and selfish, and is a waste of your time and mine. The Apple store is over there. Do yourself a favour and buy a nice new mini, and don't use TenFourFox. Above all else, don't complain to me about it. Ranty bit over.
Anyway, that wasn't directed at you guys, the loyal supporters. You get the good stuff. Read the release notes, then grab for your architecture:
Monday, October 3, 2011
7.0.1 under review
Mozilla has released a chemspill for 7, but not for the bug you would expect (viz., the BEAST SSL issue we talked about last blog entry). Instead, this release covers bug 680802 and an unusual case where simultaneously trying to update the browser and an add-on causes the add-on to be apparently lost (in reality it is simply hidden and doing operations in the Add-on Manager will "resurrect" it).
After reviewing the bug, this appears to be another case where our more limited functionality saves us again. Although I can think of some scenarios where you could get a simultaneous update, because TenFourFox forces you to download a whole new copy of the browser for updates due to our more limited infrastructure you will rarely be updating both add-ons and the browser at the exact same time; instead, you update TenFourFox, it downloads new versions, and life goes on. It is possible to trip the bug, but you really have to work at it and I'll just let you think of how that might occur. I have only had one report of Adblock getting waxed updating to 7.0, and the user was able to manually restore it afterwards.
Because point releases are expensive for us and because I believe the risk is low, the current plan is not to release a 7.0.1. If you are one of those few unfortunate people who did manage to figure out how to louse up the browser and your add-ons, Mozilla has an add-on (ha!) that will temporarily patch the issue. You can download the add-on repair tool from Mozilla directly. Please report any irregularities.
8.0 beta is currently running in debugging mode internally. Mozilla, damn them, has significantly rewritten large portions of the widget toolkit requiring some extensive backouts and patching to work on 10.4, so we will likely drop parity shortly with widgets. The browser, however, basically works and I hope to have the beta out by the end of the week. There are some great TenFourFox-specific features in it too. More about that soon.
After reviewing the bug, this appears to be another case where our more limited functionality saves us again. Although I can think of some scenarios where you could get a simultaneous update, because TenFourFox forces you to download a whole new copy of the browser for updates due to our more limited infrastructure you will rarely be updating both add-ons and the browser at the exact same time; instead, you update TenFourFox, it downloads new versions, and life goes on. It is possible to trip the bug, but you really have to work at it and I'll just let you think of how that might occur. I have only had one report of Adblock getting waxed updating to 7.0, and the user was able to manually restore it afterwards.
Because point releases are expensive for us and because I believe the risk is low, the current plan is not to release a 7.0.1. If you are one of those few unfortunate people who did manage to figure out how to louse up the browser and your add-ons, Mozilla has an add-on (ha!) that will temporarily patch the issue. You can download the add-on repair tool from Mozilla directly. Please report any irregularities.
8.0 beta is currently running in debugging mode internally. Mozilla, damn them, has significantly rewritten large portions of the widget toolkit requiring some extensive backouts and patching to work on 10.4, so we will likely drop parity shortly with widgets. The browser, however, basically works and I hope to have the beta out by the end of the week. There are some great TenFourFox-specific features in it too. More about that soon.
Tuesday, September 27, 2011
BEAST smothered by security blanket
7.0 was converted to final this morning and I'm pulling down 8 beta 1 for initial conversion as we speak. This will require more work than 7 because Mozilla committed a number of 10.5/10.6-specific widget changes which will need to be rewritten for 10.4, but I'm pretty confident this is possible. You'll be the first to know.
A number of people have privately asked me whether TenFourFox is susceptible to the BEAST SSL attack revealed over the weekend. This rather startling hack was able to decrypt a Paypal cookie sent over SSL, allowing the attacker to assume the identity of the logged-in user. It should come as no surprise that 1) the Mozilla security team has been discussing this (along with representatives from Google, which uses the Netscape-originated Network Security Services library also) for several months, and 2) as shipped, TenFourFox is not vulnerable. Notice that I said "as shipped." The exploit demonstrated by Rizzo and Duong used a Java applet to do the server thrashing needed to get the key out, and TenFourFox disables all plugins including the Java Embedding Plugin, so the applet cannot run. It may be possible to do something similar in Flash (though such code has not yet? surfaced), but obviously this doesn't ship enabled in TenFourFox either, and the version of WebSockets in Firefox 7 and TenFourFox 7 cannot be used to trigger this exploit.
Even with plugins, Java and/or other suitable footholds available, the SSL flaw in question is not trivial to exploit: not impossibly hard nor prohibitively expensive, but neither is it simple, quick or easy. An attacker must have control of the network the victim is using (such as a compromised or open wireless link), and must be fast enough to spy on the connection and manipulate the victim's browser to try combinations on the server the victim is accessing before the session terminates. Under the optimal conditions of the demonstration the "victim" was pwned in about two minutes; real world assaults will undoubtedly require significantly more time. It is also possible for servers to immunize themselves against the attack by negotiating ciphers that are not vulnerable to the flaw Rizzo and Duong are taking advantage of; RC4/ARC4 is one such cipher and Google is using it already on its services.
The best solution is to leave TLS 1.0 behind, but for a variety of reasons this has yet to happen, and perhaps this will be the impetus to change to a safer, later TLS version. Once a final fix is decided upon for NSS, there may or may not be a 7 chemspill; we'll follow Mozilla's lead here. A similar fix will be included in Classilla, which is technically vulnerable but hard to exploit because OS 9's MRJ is mercifully too old and Flash 7 does not support sockets of the type required.
A number of people have privately asked me whether TenFourFox is susceptible to the BEAST SSL attack revealed over the weekend. This rather startling hack was able to decrypt a Paypal cookie sent over SSL, allowing the attacker to assume the identity of the logged-in user. It should come as no surprise that 1) the Mozilla security team has been discussing this (along with representatives from Google, which uses the Netscape-originated Network Security Services library also) for several months, and 2) as shipped, TenFourFox is not vulnerable. Notice that I said "as shipped." The exploit demonstrated by Rizzo and Duong used a Java applet to do the server thrashing needed to get the key out, and TenFourFox disables all plugins including the Java Embedding Plugin, so the applet cannot run. It may be possible to do something similar in Flash (though such code has not yet? surfaced), but obviously this doesn't ship enabled in TenFourFox either, and the version of WebSockets in Firefox 7 and TenFourFox 7 cannot be used to trigger this exploit.
Even with plugins, Java and/or other suitable footholds available, the SSL flaw in question is not trivial to exploit: not impossibly hard nor prohibitively expensive, but neither is it simple, quick or easy. An attacker must have control of the network the victim is using (such as a compromised or open wireless link), and must be fast enough to spy on the connection and manipulate the victim's browser to try combinations on the server the victim is accessing before the session terminates. Under the optimal conditions of the demonstration the "victim" was pwned in about two minutes; real world assaults will undoubtedly require significantly more time. It is also possible for servers to immunize themselves against the attack by negotiating ciphers that are not vulnerable to the flaw Rizzo and Duong are taking advantage of; RC4/ARC4 is one such cipher and Google is using it already on its services.
The best solution is to leave TLS 1.0 behind, but for a variety of reasons this has yet to happen, and perhaps this will be the impetus to change to a safer, later TLS version. Once a final fix is decided upon for NSS, there may or may not be a 7 chemspill; we'll follow Mozilla's lead here. A similar fix will be included in Classilla, which is technically vulnerable but hard to exploit because OS 9's MRJ is mercifully too old and Flash 7 does not support sockets of the type required.
Friday, September 23, 2011
Super omnibus update: 7.0 RC, updated QuickTime Enabler, and Floodgap is back up
Well, heck, let's start with the good news first. AT&T installed the T1 on Monday and DSL Extreme activated it earlier today, so Floodgap and its associated projects, including TenFourFox.com, is back online. Point your friends, enemies, rather less good enemies of theirs and friends of those people's less good enemies to it.
The T1 comes at (naturally) a substantially greater hosting cost; though it is amortized against using it for my other projects and as my regular means of Net access, it's still a pricey (but very smooth and low-latency) way of getting hosts online compared to DSL or cable, neither of which were practical options for reasons many of you already know. As a policy matter I do not accept project donations as this has the risk of encouraging expectations I and the other contributors can't satisfy, but I am considering allowing Blogger to put ads on this blog to make a little of the money back. I won't object if you Adblock them away, of course.
Mozilla has signed off on the 7 release candidate, so now we have our release candidate available ahead of Firefox 7's formal launch on September 27th. As with previous release candidates, if there are no showstoppers then this will become the formal release. There is one small fix in this version (in addition to Mozilla's fixes): because Floodgap was down there was nothing to post update snippets against, so this fix adds the 7-specific update checks. As a result, there is also a new set of changesets for builders. Read the release notes and grab for your architecture:
Also available, as promised in the previous blog entry, is a new version of the TenFourFox QuickTime Enabler. If you are new to the QTE, please see this blog entry for basic instructions; in short, the QTE allows you to play certain media types outside of the browser in QuickTime, including H.264 video (which Firefox can't play at all) and most other audio and video files by right-clicking and selecting Open Media in QuickTime. In alpha-45, here's what's new:
"One more thing." Many of you will have read the press coverage about the "BEAST" SSL chosen plaintext attack demonstrated at ekoparty this weekend. Virtually every browser is vulnerable to this; Opera has already released a patch and Chrome has one in testing. Note that Mozilla and Chrome share SSL code (i.e., they both use NSS), so the same fix is likely to appear in Firefox, but it is not currently in 7. There is substantial argument about how easy it is to pull off in practice, but certain things can make it easier, and we might talk about this once Mozilla goes public with a final determination.
Man, it's good to be online again.
The T1 comes at (naturally) a substantially greater hosting cost; though it is amortized against using it for my other projects and as my regular means of Net access, it's still a pricey (but very smooth and low-latency) way of getting hosts online compared to DSL or cable, neither of which were practical options for reasons many of you already know. As a policy matter I do not accept project donations as this has the risk of encouraging expectations I and the other contributors can't satisfy, but I am considering allowing Blogger to put ads on this blog to make a little of the money back. I won't object if you Adblock them away, of course.
Mozilla has signed off on the 7 release candidate, so now we have our release candidate available ahead of Firefox 7's formal launch on September 27th. As with previous release candidates, if there are no showstoppers then this will become the formal release. There is one small fix in this version (in addition to Mozilla's fixes): because Floodgap was down there was nothing to post update snippets against, so this fix adds the 7-specific update checks. As a result, there is also a new set of changesets for builders. Read the release notes and grab for your architecture:
Also available, as promised in the previous blog entry, is a new version of the TenFourFox QuickTime Enabler. If you are new to the QTE, please see this blog entry for basic instructions; in short, the QTE allows you to play certain media types outside of the browser in QuickTime, including H.264 video (which Firefox can't play at all) and most other audio and video files by right-clicking and selecting Open Media in QuickTime. In alpha-45, here's what's new:
- Updated for Gecko 7 (alpha-43 will not work with 7.0)
- Overly long URLs don't cause garbage characters in the URL dialogue anymore; they will simply be truncated (but will still play)
- If you are not offered the QuickTime option initially, start to play the video. When the video appears and starts, right click again and see if the option is offered then. If it is, and you open the file in QuickTime, the enabler will now automatically stop the video in the browser (if possible) so that you aren't playing it in two places. This should enable JavaScript-based video code that tries to detect browser capabilities to also be playable in the Enabler.
"One more thing." Many of you will have read the press coverage about the "BEAST" SSL chosen plaintext attack demonstrated at ekoparty this weekend. Virtually every browser is vulnerable to this; Opera has already released a patch and Chrome has one in testing. Note that Mozilla and Chrome share SSL code (i.e., they both use NSS), so the same fix is likely to appear in Firefox, but it is not currently in 7. There is substantial argument about how easy it is to pull off in practice, but certain things can make it easier, and we might talk about this once Mozilla goes public with a final determination.
Man, it's good to be online again.
Sunday, September 4, 2011
7.0b1 available, whither 6.0.2, and a special pirate edition: YARR, THIS INTERPRETER SUX
So, it's Labor Day weekend and I've spent it watching Law and Order DVDs, painting the house trim and tweaking TenFourFox. Today, for those of you with nothing better to do on a holiday weekend either, 7.0 beta 1 is available, roughly corresponding to Firefox 7 beta 4. Generally I am loathe to talk about subjective speed improvements in this blog because they are just that, subjective. However, there is a lot to like about Fx7, and the biggest one isn't the memory footprint improvements (because we're forced to take a hit on that, read on). Instead, it's the graphics stack, and the new Cairo really benefits our rendering pipelines. Pages paint quicker, animations are snappier and movie playback is less jerky. The improvement is subtle, and there is still much improvement to come, but I think virtually everyone will notice the difference. Tobias, the early trailblazer on 7, said it was the first version he felt was truly useable on his PowerBook. While I politely demur that I've been perfectly happy with TenFourFox on my iBook G4 ;) , I certainly do agree that 7 is better in nearly every metric.
Also new in 7 is the beginnings of a new HTML5 canvas backend (Azure, which will eventually take over the entire rendering pipeline; fortunately for us, the CoreGraphics version is likely to work and even if it doesn't there's still Cairo), improvements to Sync, a new Telemetry module for reporting performance back to Mozilla (we don't track this information ourselves, but if you want to remind Mozilla that PowerPC lives, go for it :), a new API for sites to determine load times and adjust themselves to slower systems, and CSS3 ellipsis support.
Oh, and it takes http:// out of the menu bar. Strangely, I'm not as offended by this as I thought I would be, but I'm not wild about it. gopher:// does still appear, though, and so does https://, so I guess that's all that matters. :D
So, yeah, about that "memory footprint" thing. Firefox 7 is being touted as the first product of Mozilla's MemShrink project, bragging numbers that reduce its overall memory usage by 20-50%, will leak considerably less, and will more aggressively release memory as tabs are closed. Naturally such must be taken with a grain of salt, but I will say that memory usage is noticibly less on both my G5 and my iBook. In typical usage on the iBook, comparing 6 versus 7, 7 seems to use about 25% less memory, and the system is able to reclaim it more easily.
Our problem, however, is it appears we are dramatically underestimating the PowerPC's JavaScript stack demands. Longtime TenFourFox veterans will recall several bugs that in succeeding order jack up the stack ceiling more and more, and in this version we jump from 64MB of stack to 256MB of stack (repairing issue 85). This is unfortunately unavoidable because the PowerPC ABI requires us to save registers to the stack on function calls and the PPC has a massive number of registers. As OS X has a hard cap limit we must ask for this cap in advance, and the original limits we asked for were too small because our stack frames are so much larger, causing it to crash out on certain scripts. This means in the worst case the browser may require a minimum of 256MB of RAM just for the stack, let alone the app or the rest of the OS. For this reason, starting with 7.0, the minimum system requirements will be for 512MB of physical memory. Systems with 256MB of RAM will no longer be supported. Every Power Mac we support in TenFourFox is capable of at least that much; even my Outrigger beige Power Mac 7300 has a gig, and my blueberry iBook G3 has 576MB. The recommended minimum will now move to 768MB. Fortunately, thanks to the other improvements, you'll be able to do more with the rest of your memory, and the 256MB is only a peak possibility, not a persistent requirement. So do yourself and your Mac a favour (RAM is dirt cheap these days) and max out your memory now.
A few of you will be wondering about that cryptic title, and that's the other thing that we need to mention: YARR sucks. Mozilla is expanding their JIT to JavaScript regular expressions using WebKit's YARR library. YARR originally used the Perl-Compatible Regular Expression library (or at least their heavily hacked version of it) as the interpreter fallback for when a JIT was not available, and since we don't (yet) have support for methodjit or the Nitro assembler on PowerPC, we used PCRE for regexp evaluation. In 7.0 Mozilla "upgraded" YARR to a version that now uses its own interpreter as the fallback instead of PCRE. All of their shipping platforms use the JIT, which to be sure, is very quick.
We knew about this going in and several of Tobias' patches were to fix the JavaScript core to deal with the situation where the YARR JIT was not enabled. When I got this together and ran it through Dromaeo for conformance testing, however, I was shocked to see the G5 drop from 110+ runs/sec (in 6) to a dismal 65. All of this regression was paid on the regular expression part of the benchmark. When I hacked PCRE back into the JSRegExp portion of the library, the number went back to the old figure. While WebKit admits benignly that YARR's interpreter is "slower" than PCRE, frankly we really take it in the shorts with YARR and so will any other tier-3 platform that doesn't yet have methodjit/macro assembler support. I filed this with Mozilla as bug 684559 so they can ignore it, but we are shipping with PCRE back because we can't afford a hit like that. Eventually we will have methodjit and we can play in the full JIT party too, but that won't be for a couple cycles yet.
Specific to us, because of my continuing downtime (AT&T is coming out to look at installing a second NID this week for my T1), there has not been any new TenFourFox-specific features in 7 other than updating Sluggo for the new Apple CEO. However, as mentioned, issue 85 is repaired, and a 10.5 specific bug with dropdowns (issue 72) has a putative fix. This fix is limited to 10.5; if you are one of those affected by that bug, please let me know if triggering dropdowns actually crashes the browser instead, because this would imply that my theory is incorrect (i.e., that issue 9 should only be worked around on 10.4). 10.4 is not affected by this issue. This version does not fix issue 84, the table spacing issue; although we have test cases, we haven't narrowed it down to the exact Mozilla patch that provoked the issue and I don't want to wreck my one working 6 repo until I don't need it anymore since none of my ad-hoc offline repos have history. As this bug is a simple nuisance, occurs only on certain sites and the sites in question are otherwise useable, we're shipping with this bug for now.
Soon we will need to turn our efforts to methodjit so that we can keep pace with Mozilla's improvements to JavaScript. If you know PowerPC assembly language and want to help, we can always use more coders.
I'm also working on a new release of the TenFourFox QuickTime Enabler. Watch for it in the coming week or two.
In news from the Mountain View mothership, Mozilla is planning a chemspill for their chemspill, viz., a Firefox 6.0.2. This version "fixes the fix" for DigiNotar, which seems to have caused some collateral damage, but their fix-fix is similarly controversial. I am not planning to generate a 6.0.2 as 6.0.1 will fail safe and I'm not convinced there won't be more changes in the pipeline before 7 emerges. If you are affected by the changes in 6.0.1, you could always use this beta, of course. :) However, if there is a large demand for it, I will consider releasing it as well.
For now, read the 7.0 beta release notes, and grab for your architecture:
Also new in 7 is the beginnings of a new HTML5 canvas backend (Azure, which will eventually take over the entire rendering pipeline; fortunately for us, the CoreGraphics version is likely to work and even if it doesn't there's still Cairo), improvements to Sync, a new Telemetry module for reporting performance back to Mozilla (we don't track this information ourselves, but if you want to remind Mozilla that PowerPC lives, go for it :), a new API for sites to determine load times and adjust themselves to slower systems, and CSS3 ellipsis support.
Oh, and it takes http:// out of the menu bar. Strangely, I'm not as offended by this as I thought I would be, but I'm not wild about it. gopher:// does still appear, though, and so does https://, so I guess that's all that matters. :D
So, yeah, about that "memory footprint" thing. Firefox 7 is being touted as the first product of Mozilla's MemShrink project, bragging numbers that reduce its overall memory usage by 20-50%, will leak considerably less, and will more aggressively release memory as tabs are closed. Naturally such must be taken with a grain of salt, but I will say that memory usage is noticibly less on both my G5 and my iBook. In typical usage on the iBook, comparing 6 versus 7, 7 seems to use about 25% less memory, and the system is able to reclaim it more easily.
Our problem, however, is it appears we are dramatically underestimating the PowerPC's JavaScript stack demands. Longtime TenFourFox veterans will recall several bugs that in succeeding order jack up the stack ceiling more and more, and in this version we jump from 64MB of stack to 256MB of stack (repairing issue 85). This is unfortunately unavoidable because the PowerPC ABI requires us to save registers to the stack on function calls and the PPC has a massive number of registers. As OS X has a hard cap limit we must ask for this cap in advance, and the original limits we asked for were too small because our stack frames are so much larger, causing it to crash out on certain scripts. This means in the worst case the browser may require a minimum of 256MB of RAM just for the stack, let alone the app or the rest of the OS. For this reason, starting with 7.0, the minimum system requirements will be for 512MB of physical memory. Systems with 256MB of RAM will no longer be supported. Every Power Mac we support in TenFourFox is capable of at least that much; even my Outrigger beige Power Mac 7300 has a gig, and my blueberry iBook G3 has 576MB. The recommended minimum will now move to 768MB. Fortunately, thanks to the other improvements, you'll be able to do more with the rest of your memory, and the 256MB is only a peak possibility, not a persistent requirement. So do yourself and your Mac a favour (RAM is dirt cheap these days) and max out your memory now.
A few of you will be wondering about that cryptic title, and that's the other thing that we need to mention: YARR sucks. Mozilla is expanding their JIT to JavaScript regular expressions using WebKit's YARR library. YARR originally used the Perl-Compatible Regular Expression library (or at least their heavily hacked version of it) as the interpreter fallback for when a JIT was not available, and since we don't (yet) have support for methodjit or the Nitro assembler on PowerPC, we used PCRE for regexp evaluation. In 7.0 Mozilla "upgraded" YARR to a version that now uses its own interpreter as the fallback instead of PCRE. All of their shipping platforms use the JIT, which to be sure, is very quick.
We knew about this going in and several of Tobias' patches were to fix the JavaScript core to deal with the situation where the YARR JIT was not enabled. When I got this together and ran it through Dromaeo for conformance testing, however, I was shocked to see the G5 drop from 110+ runs/sec (in 6) to a dismal 65. All of this regression was paid on the regular expression part of the benchmark. When I hacked PCRE back into the JSRegExp portion of the library, the number went back to the old figure. While WebKit admits benignly that YARR's interpreter is "slower" than PCRE, frankly we really take it in the shorts with YARR and so will any other tier-3 platform that doesn't yet have methodjit/macro assembler support. I filed this with Mozilla as bug 684559 so they can ignore it, but we are shipping with PCRE back because we can't afford a hit like that. Eventually we will have methodjit and we can play in the full JIT party too, but that won't be for a couple cycles yet.
Specific to us, because of my continuing downtime (AT&T is coming out to look at installing a second NID this week for my T1), there has not been any new TenFourFox-specific features in 7 other than updating Sluggo for the new Apple CEO. However, as mentioned, issue 85 is repaired, and a 10.5 specific bug with dropdowns (issue 72) has a putative fix. This fix is limited to 10.5; if you are one of those affected by that bug, please let me know if triggering dropdowns actually crashes the browser instead, because this would imply that my theory is incorrect (i.e., that issue 9 should only be worked around on 10.4). 10.4 is not affected by this issue. This version does not fix issue 84, the table spacing issue; although we have test cases, we haven't narrowed it down to the exact Mozilla patch that provoked the issue and I don't want to wreck my one working 6 repo until I don't need it anymore since none of my ad-hoc offline repos have history. As this bug is a simple nuisance, occurs only on certain sites and the sites in question are otherwise useable, we're shipping with this bug for now.
Soon we will need to turn our efforts to methodjit so that we can keep pace with Mozilla's improvements to JavaScript. If you know PowerPC assembly language and want to help, we can always use more coders.
I'm also working on a new release of the TenFourFox QuickTime Enabler. Watch for it in the coming week or two.
In news from the Mountain View mothership, Mozilla is planning a chemspill for their chemspill, viz., a Firefox 6.0.2. This version "fixes the fix" for DigiNotar, which seems to have caused some collateral damage, but their fix-fix is similarly controversial. I am not planning to generate a 6.0.2 as 6.0.1 will fail safe and I'm not convinced there won't be more changes in the pipeline before 7 emerges. If you are affected by the changes in 6.0.1, you could always use this beta, of course. :) However, if there is a large demand for it, I will consider releasing it as well.
For now, read the 7.0 beta release notes, and grab for your architecture:
Wednesday, August 31, 2011
6.0.1 now available
6.0.1 is now available. As mentioned in the previous blog entry, this repairs the issue with fraudulent SSL certificates released by DigiNotar. Please note that all previous versions of TenFourFox are vulnerable to these certificates, so you are strongly urged to upgrade. There are no other changes to this version, and as such, there is no new changeset pack for builders (the old 6.0 one continues to apply to the current release repository). Read the release notes, then grab for your architecture:
Subscribe to:
Posts (Atom)