Friday, June 29, 2012

If you're in China's less well-behaved territories and you use a Power Mac, looks like the People's Glorious Malware Factory No. 1 has something for you too. Jokes aside, Kaspersky is reporting a Universal version of the MaControl trojan attached to E-mails apparently trying to spearphish Uyghur Mac users. Trojans aren't really anything new to our world, of course; there are a number of older trojans which will successfully run on and attack Power Macs, very few of which remain in the wild. MaControl, however, is an advanced persistent threat-type infection that has a long history of use by Chinese hacker-enforcers, and to my knowledge this is the first time that it has been made "available" to Power Mac users, meaning at least someone out there still remembers us in our little RISC foxhole. It may also be a recognition that in those far-flung regions older non-Intel Macs are probably still seeing significant usage, the Dalai Lama's karma-depleting use of inferior Intel technology notwithstanding. So be careful about strange E-mails bearing strange .apps.

I am working on the Fx15 port a bit early, which is being bogged down by the MPL license change invalidating many of our patches and DOM event changes requiring some big surgery to widget/. More on that later. However, we are still on schedule for an Fx14/10.0.6 release around July 13, and Classilla users will also be happy to hear that several major security flaws have been eradicated from 9.3.1 so far; the audit is now almost to the Mozilla 1.8 era and the review process should get faster then as many of the flaws will start to cover code that doesn't exist in Classilla.

Saturday, June 23, 2012

A snapshot of changesets for 14.0 (mozilla-beta) is now available. This is not a major release for Mozilla; about the only user-facing change of significance is that favicons in the address bar are now replaced with a security indicator (globe means insecure; padlock means SSL; green padlock with name means SSL with an EV cert). This is a good adjustment because a common support question is "where did the padlock go? am I secure?" and I think Mozilla got enough of these to reintroduce that reassurance. There are some performance adjustments and a few new CSS features, but other than that nothing amazingly impactful, and click-to-play turned out to be a non-issue for us.

The only other thing to note is that this release also adds support for GStreamer decoding, but it isn't enabled in any released builds, and I am not aware of a prefab PPC GStreamer library we can just use. I am very nervous about us maintaining our own GStreamer; I'd prefer to have that outside of the browser for legal reasons, and be aware that GStreamer only adds the codec -- it does not necessarily improve performance, and QTE will still be faster on those sites it supports. This would just be for those sites that QTE can't currently deal with, like Vimeo.

On our end, however, we have some fires to put out. This version does include the JavaScript compiler latency patch from issue 160 and a crash fix discovered during the investigation of issue 165, and both of these patches will also be in 10.0.6. (Between the latency patch and general improvements in 14, I am now able to blog again with the G5 in reduced performance, which is great for beating the Southern California heat in my home office. Unfortunately, it seems our aggressively small, not-quite-ABI-compliant stack frames are catching up with us, but I'd prefer to delay any invasive surgery at that level until IonMonkey.) Furthermore there are some breaking changes Tobias found in Fx15, so after this I will pull down a copy of the 15 alpha and try to get started on it early (plus, I want to add the QTE as part of the base browser in this release, which is not complicated, but not trivial). However, the biggest problem is that I had to actually comment code out and back out other Mozilla changes to avoid compiler bugs; gcc 4.0.1 is no longer able compile some components in content/ without crashing. Mercifully the code that I jettisoned was non-essential, but it's inevitable we will get something like this in code that actually makes a difference.

We need to also combine this with the Mozilla Mac developers getting more insistent about ending 10.5 support. The current proposal is now to end 10.5 support with Firefox 17, which would really suck, because we would have to add that stripped code back in immediately for what would have been our next stable release on 17ESR. Fortunately I am not the only one with that opinion, and no decision has been made. We need to be reasonable about this; Mozilla has a lot of hacks in their code to deal with 10.5 deficiencies, and it does cause them additional material work in that regard, so I understand their point of view. Nevertheless, if we can get them to hold off on dropping Leopard until Fx18, we will be in much better shape.

These are the first rumblings of what I will call, with my characteristic hyperbole, Judgment Day. Assuming Mozilla agrees to hold 10.5 support through 17, Fx18 will be a major reworking for us: we will need our own theme and widget to escape 10.6+ API hell, we may or may not need to start working on IonMonkey, and we will definitely move to gcc 4.6. All of these foundational adjustments are big-league port changes and will almost certainly introduce bugs and parity gaps, so we'll really need a stable footing for our proletariat while the plumbing gets reworked in the new unstable branch. The only question after that is whether there will be a 24ESR and Mozilla has not said. In my best Arnold Schwarzeneggar voice, I can only say that "we'll be back."

Wednesday, June 13, 2012

Mozilla is issuing a 13.0.1 for release probably by Friday to address bug 733614 and bug 756850. Allegedly bug 736731 (MS Messenger and Hotmail bustage) is also being addressed, but there is no code attached to that bug. Neither of these issues I consider heavy enough hitters to respin for unstable, and both of them will be picked up in 14 anyway, the port of which will start when "beta 8" (really beta 3 by any other name) comes out sometime next week.

13 has turned out to be another problematic release for our friends in Mountain View. Besides these issues above forcing a chemspill, which is never desirable, the highly hyped New Tab page is really unpopular in SUMO. Even considering the fact that the displeased are usually the most visible, New Tab comments are 76% negative. Fortunately, it is pretty easy to turn off with the cube icon at the top right, or by a dive into about:config (browser.newtabpage.enabled to false, or browser.newtab.url to about:blank), but someone apparently forgot to tell the peanut gallery. There are also sporadic reports of issues with SPDY on Gmail and Twitter.

With regard to 14, the changes are largely at the UI level. 14 introduces the first support for plugin click-to-play, but this isn't enabled by default, and it doesn't change the fact we don't support plugins anyhow (this just guards against drive-by attacks, not errant clicks, so I don't consider it to be enough of a satisfactory security solution with the state of PowerPC plugins). It also does some more rearranging of the deck chairs by changing the address bar iconography for secure sites, again, but the Awesome Bar is now smarter about hostnames and domains, and that is a welcome change; there is also initial support for the Pointer-Lock API for games, and some performance improvements. Note that those of you who have used the AuroraFox build on 10.5 will have probably seen this already. The big improvements are still not scheduled until Fx15, and Tobias' early work indicates we have some compatibility issues we will need to work out with the JIT plus bustage from the libvpx upgrade in that release, so I might start that port early to see how much damage there is.

In the meantime, the optimization in issue 160 for JavaScript has performed very well on the 7450 10.0.5 test build, so it will be rolled out for 14 and 10.0.6. Watch for 14 probably in about two weeks.

Saturday, June 2, 2012

10.0.5 is available for testing prior to release. Please ensure it operates to your satisfaction. After the release of 13 when I was reviewing code, it dawned on me that we have a low-hanging inefficiency in our methodjit backend that we can simply remove in optimized builds. Because this removes an assertion, even a dead one, I eventually decided not to ship it in 10.0.5, but it will be shipped in 14 and then ultimately 10.0.6. The tweak reduces JavaScript compiler latency and improves performance on V8 by a consistent 1-2%, but it is likely to improve small scripts even more because compiler latency is a larger proportion of their runtime. I have issued a 7450-only test build for this tweak, since I do my 10.x testing on a 7450 system, but if you want to build your own with it and test it yourself the patch is in issue 160. Please test the official build (below) before testing this one. Don't compare performance to 13; 13 is already significantly faster and this would simply add icing to the cake.

A polite note for pedants and download aggregators, since I am starting to get spurious mail and bug reports about this: the availability of this build doesn't mean it's generally available; this is for last-minute RC testing. Our release dates correspond broadly with Mozilla's and version alerts will not be updated until Monday.

10.0.5 also marks the general availability of language pack installers, for stable branch users only. Many thanks to Chris and our localizers! If you have not tested them yet, please choose German, French or Polish from the Downloads tab, and report your results. The installers will work on any 10.x version of TenFourFox from 10.0.3 on up; they are distributed as actual installers, not as standard Firefox .xpis. Do not use them with the unstable versions.

I am considering further improvements to JavaScript compiler speed and a straightforward one is to simply mark all the trivial codegen functions in PPCAssembler.h as inline. The problem is I'm not sure this will make it any faster, since gcc is probably inlining some of them anyway; about the only thing I am sure about is that it will definitely make the binary larger. I'll be doing some testing of this when I begin the port for 14. This change will probably not be backported to stable unless it is a massive win.

The port for 14 will begin with beta 8 (14 betas will start with 5 to harmonize numbering with Fennec). For now, 10.0.5 release notes and official arch builds follow; if there are no issues these will finalize on Monday: