Don't throw tomatoes ... but there's an Intel version

UPDATE: to whomever posted this to root86, do us all a favour and either link this post or the IntelBuild wiki page. It's uncool to offer an unsupported product without comment and not allow people to read about the support level first. I really don't want to get people complaining down the road if this port goes off the rails. Fix your link, please.

Remember in 1997 how Bill Gates appeared at Macworld with Steve-O and got booed because the enemy was now within the gates? Well, this is like that.

At least one of you has discovered the work of our newest contributor Claudio, who contributed patches in issue 204 for enabling TenFourFox 17 to build on Intel 10.4. This is a common question I get ("why is TenFourFox not universal? why doesn't it work on my MacBook?"), so Claudio has graciously consented to handling the Intel fork for the moment. Beforehand, however, let's get a few things straight:

• PowerPC remains the primary architecture of development for TenFourFox. The Intel version is a sideline maintained by an interested contributor. This is, as Apple says about AppleTV, a "hobby." The Intel version will never delay the PowerPC version, which is the primary focus of development, nor will unnecessary limitations required for an Intel build be applied to a PowerPC build (we have enough of our own limitations to worry about), nor will it be offered on the main page for the foreseeable future.
• If you own an Intel Mac running 10.4 or 10.5, your best option is still to upgrade to at least 10.6 and run real honest-to-JWZ Firefox. This is only for those people who for some reason can't or won't upgrade, and understand the risks of staying with 10.4 or 10.5 (which are much higher in practice than the risks to Power Mac users with the same versions).
• I don't build the Intel version (I have a single solitary 10.6 Intel Mac); Claudio builds it himself. I haven't even tried running it yet, but the patches look good.
• The Intel version, as well as trying to run the PowerPC version under Rosetta, is unsupported. Let me say that again. The Intel version, as well as trying to run the PowerPC version under Rosetta, is unsupported. Do not report bugs to Tenderapp. You may report them to the Google Code project (as you may for unstable releases), but bugs reported to the Google Code project are under the same limitations: you must test them under Firefox on a Tier-1 architecture before you make any report to demonstrate the bug is not Mozilla's or the bug will be marked invalid. And, even if you do report it, the Intel fork is not release quality. It's an experiment. Bugs, even major ones, may not be repaired quickly or at all, and releases may not be timely. If you want a real release quality Firefox on Intel, do yourself a favour and upgrade to 10.6.
• The Intel version may cease development at any time. Right now it works with 17. We have not tried getting 19 to compile, though it probably will, but you shouldn't assume that nor that there will be even another ESR release of the browser. There. Is. No. Support.

The long and short: don't make me or Claudio regret offering this, okay? If you are expecting the same level of quality or service you get from Firefox or from mainline PowerPC TenFourFox, do not download this browser.

Having scared the entitled cheapskates off to OmniWeb, those of you in this very, very, very small demographic can get the download link and a refresher course on the very many limitations attached to it from the "official" Intel build Wiki page.

Back on regular development, 19 has had a lot of display and graphics issues, as expected. The good news is most of these will be corrected. More on that as the final release approaches.

TenFourFox 19 beta: Judgment Day

COMING TO A POWER MAC NEAR YOU
RATED PG-19 FOR A PRETTY GOOD PORT OF 19 BETA

Yes, it's Judgment Day, and we've been judged absolutely righteous. Mozillanet has exterminated all 10.4 and 10.5 computers from the earth web, but the resistance has sent their computers forward in time with the use of advanced compiler technology to save 21st-century humanity from Intel-based hunter killers and Tim Cook drones. Excuse me, there's a police officer at the front door who bears a strange resemblance to Robert Patrick. I'll be back.

And I'm out of desperate Terminator jokes, so here's TenFourFox 19. Our personal "judgment day" was the end of 10.5 support in Firefox, officially in 16 (but 10.5 code was kept by arrangement in 17 so we could reenable it in the ESR), and the need to upgrade our compiler toolchain to a later gcc/bintools due to unacceptable hacks needed to get gcc 4.0.1 to work. Our compiler adventures were already excessively documented in this august publication, and the rest of the work was upgrading our build system to handle the new compiler and build independent binaries, and lastly finding and restoring the code Mozilla deleted or changed for the new 10.6 baseline. So now you have it in front of you to try.

This port was the opportunity to pay off much of our accumulated technical debt. The compiler upgrade alone allows us access to better PowerPC code generation and optimizations, and it also allowed me to jettison many of the gcc 4.0.1 compiler hacks that hampered portability. Because of improvements in the standard libraries also available in gcc 4.6.3, we now carry our own copies of libgcc and libstdc++ instead of using the system ones and the internal js, firefox, XUL and dylibs are all linked against it to make a self-contained package. Tobias already worked out most of this for AuroraFox, which uses a later gcc as well, although it required some tweaking for current MacPorts and 10.4. However, binaries are not significantly larger since the new linker we are using is also more efficient. My original fears about memory bloat do not appear to have been realized, either, so we are probably still okay with a 512MB RAM supported minimum. (Users at this minimum should test and report in.) Builders should note that our HowToBuildNow document now has a new section for our 19+ releases.

The new hotness has been pretty thoroughly tested on both G4 arches and G5 on 10.4, but I don't have any G3 systems running 10.4 currently, and I don't run 10.5. Leopard users and G3 users, I am particularly interested in feedback.

The biggest change between 17 and 19 is the introduction of what Mozilla refers to as "display-list based invalidation," or DLBI. Introduced first in 18, it is a deceptively simple optimization that forces the layout engine to be more exacting about what it needs to have redrawn in an effort to reduce pushing unnecessary pixels around. DLBI does not make things faster, per se (and there are some edge cases where it will make performance worse), but it does make things smoother. As an example, compare my favourite even-handed American politics site, RealClear Politics, in 17.0.2 and 19b1. After you've vomited reading articles opposed to your personal views, at the top right is a marquee with arrows to go right and left. Try scrolling through them. It's not necessarily faster, but it looks a lot nicer. Another site that shows better animation is one that had me chagrined in 17, local radio station KFI AM 640. On some sites, this almost completely erases the performance loss from the layers change introduced way back between Fx3.6 and Fx4. Because we are nearly entirely rendered in software, anything that involves pushing less pixels means better performance and better animation. DLBI is that.

A large change like DLBI also means massive regression risk. In 18, Mozilla fixed quite a few of these and I expect many more. If you find a rendering difference between 19 and 17.0.2 on a site, it is imperative you do a test on a Tier 1 official Firefox build (with hardware acceleration off) to see if it occurs there too. If it does, report it to Mozilla; it's not our bug. I am sure we will have lots of regressions unrelated to this, so I really want people to not clog up the worklist with upstream problems. Remember, please do not file issues on unstable builds on Tenderapp to avoid confusing regular end users on the stable branch. And before you ask, it is not possible to backport DLBI to 17. Sorry.

19's most ballyhooed change, however, is disabled in our build: the JavaScript PDF viewer. PDF.js actually has been part of Firefox for some time, but this is the first time it is being user-exposed by default. However, it's a poorer renderer than Preview.app or (natch) Adobe Acrobat, it's a much slower renderer (its speed is at best tolerable on this quad G5), and there's some argument from security guyz on whether it's even a safer renderer. PDF rendering is going to be the next frontier for Power Mac porting, and I'm looking at updating Vindaloo to see if this can be a future means to safely handle PDF files on PowerPC, but that's another story (and it won't be integrated with the browser in any case). You can go into about:config and turn the JavaScript PDF viewer back on, and some of you already have, but I have no plans to ship that as default until the speed improves.

18 and 19 also offer rudimentary WebRTC. I need to explore this more to see if it's feasible to use on Power Macs, but given that our AltiVec WebM is really only an option for high-end G4s and G5s and we don't have any AltiVec code of any sort in WebRTC, I don't have a lot of confidence that it's going to be worth porting. Right now, it is turned off at the compiler level.

Locally, we also have some improvements of our own specific to PowerPC OS X. In addition to the same faster font enumeration code added to 17.0.2, our version of 19 also offers AltiVec-accelerated blurring and shadowing thanks to Tobias' work in issue 189. This further improves display and scrolling performance especially on pages that blur or box-shadow the entire background, requiring the CPU to do a lot more compositing work. Don't worry, G3 owners; you may not have AltiVec, but you do have a better C-language version handling the blurring/shadows for you too.

For QTE users, the QTE didn't seem to work right with 19 aurora, but seems to be okay with 19 beta (though with some errors in the console). I'm tracking this closely for now.

The biggest announcement of all, however, is that Firefox 19 is now being offered to Android handset owners with ARMv6 CPUs as "slow" as 600MHz with as "little" as 512MB of RAM. Read that carefully. Does that remind you of any particular systems on some other RISC-based platform abandoned by its manufacturer? The fact that Mozilla is now concentrating on lower-spec devices (not just for Boot2Gecko but for flagship Firefox Android) means that they will be continuing to audit for and seek performance wins in Gecko, and a lot of this will be in cross-platform code that will in turn improve performance in desktop Firefox and in TenFourFox. And that, as they say, is a Good Sign.

The T-1000 has turned itself into my cat and is busily reprogramming my security system, so you'd better get the build from the Downloads tab (and read the Release Notes) while you still can. Hasta la vista, baby.

17.0.2 RC available and that Turkdistrust thing

The build process for 17.0.2 was an unmitigated disaster all the way around, including a serious bug I introduced in one of the local patches and then a flubbed copy around 1am this morning which I discovered later had tanked the G5 and 7450 builds. Usually I have the RCs out on the Saturday prior to the Tuesday release day, but it just didn't work out that way this time around. Anyway, you can now get them from the Downloads tab and check out the release notes. This will go out on time Monday evening as usual.

This version fixes Safari bookmark importing (a Mozilla bug not uplifted to ESR), tracked as issue 194, and also revamps font scanning (issue 195). Previously, users with large numbers of fonts could have a pause of 10-20 seconds or more when the browser's character map cache was invalidated and a page with non-Latin characters was being processed (it was almost instant after the cache was filled, fortunately, but the cache is routinely invalidated in case new fonts have been loaded). Mozilla's old ATS code was actually pulling a whole font table off disk every time just to see if that table even existed (and then throwing it away!); they've moved on to CoreText-only support now that they only support 10.6 and ATS is deprecated, so they never fixed the inefficiency. So, this version loads the font table directory only and caches it, so that queries hit the directory cached in memory and this change speeds up font enumeration by about four times. Large font systems will still have a delay, but it will be much less. There is also a wallpaper fix in for malware URL validation, another Mozilla bug (tracked as issue 197).

Among the security updates in this release, it is worth mentioning the Turktrust intermediate certificate issue, which is also fixed for Classilla users as part of 9.3.2 which I released today. Intermediate and subordinate certificates have been at the heart of some of our worst SSL certificate debacles in recent memory because they explicitly delegate signing authority from a root CA to a third party that may be entirely untrustworthy. Worse, you will never be warned certificates signed by such an intermediate were not issued by a root because their trust chain directly connects them to the root from which the intermediate comes. After the DigiNotar and Comodo disasters, we've already made it clear what to do with certificate authorities who maintain inadequate security and let attackers freely generate these malicious subordinates: kill them with fire, castrate them, and subject them to Vogon poetry (oh yes, and forever tar those intermediates and the ultimately tainted root certificates as untrusted). However, Turktrust is different: the intermediate certificates seem to have been released out of what looks like sheer incompetency, and one of those intermediates was already used to construct a man-in-the-middle certificate for Google for an internal firewall in a Turkish governmental agency.

The argument is whether this merits the same kind of punishment that technical and security failure does, and my assertion is, unequivocally, yes. Administrative incompetence has the same damaging outcome as technical incompetence, viz., the further erosion of trust in the security of SSL and the risk of impersonation, and CAs with faulty internal practice should be just as subject to browser revocation and removal of their root as those who screw up technically. There can be no room for error when people's banking, money, identity and livelihoods are at stake, and the only way to make CAs participate in quality improvement is to make the penalty of failure severe, particularly if the CA already does not have a QI process (in fairness to Turktrust, they did self report the issue when it was internally discovered). Unfortunately, this won't happen that time either. Google, Mozilla and Microsoft have only rejected the particular root used to sign the intermediates, though Google also removed Turktrust from their EV certificates as an additional punishment, but as far as I'm concerned they should be completely excised. To maintain parity with Firefox, however, I have grudgingly decided to keep their other roots in for the moment while discussion about the larger problem of rogue intermediates goes on in the background.

Once 19 migrates to beta, I will apply the 19 changesets there and there will be a 19 beta. There will also need to be a new QTE based on a different jetpack due to internal changes between 17 and 19, though I will try to keep one QTE that works on both versions if possible. Hopefully I should release 19b1 sometime next week.