Monday, January 30, 2012

10 converted to release

As threatened, all update notifiers have been updated to reflect 10 to give our holdouts a chance to update while they still can. Also, I'd like to welcome Theo to our volunteer technical support squad, who has graciously volunteered to take part on Tenderapp. If you are willing to help enlighten the unenlightened as well (and file a real bug report now and then), send me an E-mail.

Sunday, January 29, 2012

10.0 RC (finally) available

The RC is finally available, after a few late-breaking bugs landed, and the G5 jammed most of the day to poot out these builds. The only difference (other than what Mozilla fixed) between this and the beta is that the help and feedback links now connect to Tenderapp, and some minor internals changes so we don't pick up Firefox hotfixes by accident. Speaking of, Mozilla did adjust garbage collection between beta and RC, and that seems a bit snappier.

I'll post more when Mozilla determines how they will maintain the ESR in their tree (no doubt as another repo). Meanwhile, 11 will be a changeset-only release because it is finally time to decommission the old Apple Network Server and I need the time to do so. Ben's changes to the methodjit branches and David's software G3/G4 square root routine will be in the next stable and unstable betas. Stay tuned.

Release notes
and builds:

Friday, January 27, 2012

Waiting for RCgodot

Ordinarily there would be RCs by now but Mozilla has not tagged the build branch yet and I know of at least one bug that may land prior to ship. Watch this space over the weekend.

Saturday, January 14, 2012

Tenderapp support now available

As I mentioned in the previous couple of posts, Mozilla will EOL Firefox 3.6 when 10 ESR exits the qualification stage (for the lifecycle of an ESR release, see the Mozilla Wiki proposal). As we are the unofficial overflow for PowerPC and 10.4 users that will be orphaned after 3.6 runs aground, we are likely to pick up a large number of new users in the very near future, and expecting Mozilla to continue to support them through SUMO is not fair on their resources.

Fortunately, Tenderapp offers free accounts to open source projects with an application, and I am pleased to announce that they have accepted ours. Starting today, users will be able to file feedback and questions through our own TenFourFox Support site. The Support link under the Help menu automatically points to this new site, there are Help and Support tabs on the main page and Start page, and the TenFourFox Help option will point to it with 10.0 final.

Please explore it and see what you think. Chris, contact me privately so I can give you a login to allow you to read and reply to support tickets. Other people who are interested in helping with the support effort, please request in the comments.

Sunday, January 8, 2012

10.0b1 stable available

Sorry about the RSS blip earlier; that was me hitting the wrong button. After a little more delay than I had previously planned, 10.0 beta is available, the first of our "stable" releases (based on the putative Firefox ESR).

Firefox 10 is actually a really strong release. In addition to the usual gratuitous UI change(s) (this time around it's the disappearing/reappearing forward button if you are using large icons in the toolbar), there are some remarkably solid additions in this release and my personal favourite is the Inspect Element feature. You can right-click on anything and select Inspect Element, and the HTML element appears in context with its children and parents, highlighted for your visual convenience. Even cooler is that you can dynamically alter the style, turn inherited and specified properties on and off, and find it within the page source. This is much like the old and much-beloved DOM Inspector (from Firefox 2.x and previous; still in Classilla and SeaMonkey) except that it is fully integrated within the main browser and not a separate XUL component. Great work, Mozilla!

Fx10 also includes 3D CSS transforms and properties. We render these in software (son of no-OpenGL-2-in-10.4), so performance is not great, but they work and they work surprisingly well, considering. Here is a static example from MDN: notice that all the 3D objects on the page are not images, but have selectable text, because they are in fact just transformed text. The proof of the pudding is in course in the animation, though, so why not a rotating HTML5 logo? Performs pretty well, even in software rendering on the 1GHz iMac G4.

Mozilla is also including a full-screen API where, if you permit it, a web page can dynamically open itself up to full screen. Now, if you're like me, you realize that the possibilities for phishing just jumped about twelve or thirteen times, and using it for full-screen video on pretty much any Power Mac is hopeless (my quad G5 even at full tilt can't push 1920x1080 WebM video in software). But it would be nice for presentations and other kinds of remotely-hosted demonstrations, and an excellent way to fool your boss that you're working (just switch to the tab with a static screenshot of Outlook taking up the whole screen :).

Finally, Mozilla has enough confidence in AMO to make extensions default to compatible. Now your addons don't get nuked every time you upgrade, unless, of course, the server says they are incompatible or they use binary or other unstable APIs. Those of you using the QTE will notice that it didn't get disabled like every other beta did. In fact, I didn't need to update any of my addons when I started using 10.0b1 personally. Nice!

Not all was wine and roses with the port. Besides breaking my keyboard over the weekend (and I really liked that keyboard, because it works well with all of my USB Macs even in OS 9), Mozilla upgraded the WebM libvpx to 0.9.7, wrecking our custom AltiVec work. This is not all bad because 0.9.7 is multithreaded and we support that on multiprocessor Macs, so this should help performance on marginal G4s with dual CPUs, and I was able to reconstruct most of our code in the end. Report irregularities.

Continuing in the bad news-good news department, tracejit is still in 10 but we can't ship it as default: SunSpider limps to a similar speed, but Dromaeo is 15-20% slower. I can't find a specific cause for this, and frankly if I try undoing things I'm likely to break JM+TI and JM+TI is the future. So the future is now. I am sufficiently confident in the performance and stability of JM+TI for it to now be the default. If you are using JM+TM, consider disabling tracejit entirely and turning on type inference before upgrading to 10 beta. I will leave tracejit in this release and the rest of the 10.0.x stable branch releases for those people who are absolutely convinced that methodjit is wrecking their machine somehow (it's not), but you need to be aware of the performance differential relative to 9, and it will not be in 11. We landed some microoptimizations and fixes in 10, but they are relatively minor and there is not much change in the numbers. However, Ben has some ideas on how to rework branches to more effectively make use of branch prediction and not make the backend insanely overcomplicated. We also have a new contributor who is working on a fast software square root for G3 and G4. This work will land on both stable and unstable, so there will be a beta for that particular stable release when it's ready.

Finally, something Mozilla did broke the way double and triple clicks select text. I think I have a workaround for it, but it might behave ever so slightly different from usual. Report non-trivial irregularities in issue 122.

Back in the good news column, Tobias' VMX text converters are patched up and back in with hardened algorithms, plus a new one for XPCOM text conversion, which should significantly restore page processing speed on G4 and G5. This completes most of the targets that support SIMD in Mozilla Core except for an obscure one that only deals with plugins, though we are always looking for others. None of these regress the infamous issue 84 and so I think we can call this a win. I also put in a minor fix to the backing JavaScript so that about:memory isn't a mess of unresolvable Unicode line drawing symbols.

It still isn't clear how Mozilla will handle the ESR rollout. My bet is that there will be a mozilla-esr repo or some such, from which we will pull for the stable releases. I am exploring low-cost ways of getting us an online helpdesk and support area for users so that we can eliminate our dependency on SUMO. Chris has volunteered to help with support. Other volunteers are requested. The beer offer stands.

For 11, we, and by "we" I mean "me," really need a break and this is the best one (closest to 10, so likely to have no major issues) to sit out on. I will still do a changeset for debug builds, but it's going to literally be just a placeholder, and there will be no binaries. If others want to take this one for the gap, go for it. Part of what I need the time for is to migrate www.floodgap.com off the 14-year-old Apple Network Server 500 that it still runs on to the big IBM POWER6 dual-core server sitting around idle except for being the gopher server and handling Veronica-2. There should be no service downtime like our unpleasant two months "network free" this summer because I'm simply going to transparently move the IP address to the new machine. I also really need to do finishing work on Classilla 9.3.0 and TTYtter 2.0 while I still have a chance. The next scheduled unstable branch release per se will be 12. I'm still planning to do it based on mozilla-beta if for no other reason than avoiding the small amount of perpetual churn on -aurora.

In the meantime, release notes and architecture builds:

Wednesday, January 4, 2012

Two forks diverged in a wood, and I, I took the one that had free beer

(* which is odd since I don't drink, but it seemed better)

It's official: Firefox 10 will be the Extended Support Release, basically Mozilla's new legacy release, and will mean the end of Fx3.6 support on April 24, 2012 (assuming current release schedule).

The ESR will mean, finally, a stable base for long term maintenance. This is of great personal relief to yours truly, because keeping up with the Mozilla treadmill ("making the hippo dance") is not a lot of fun sometimes. It is also quite possible that Mozilla will use the ESR to cast off support for OSes they don't want to support anymore (even though more progressive elements are resisting this), and I would not be surprised to see 10.5 users forced onto the ESR along with other undesirables such as Windows XP SP1 and Windows 2000.

Right now the TenFourFox 10 port is mostly done and I have a debug build mounted which appears to basically work. I have not tried getting AltiVec builds up yet; I'm planning to lock myself in my office and do that this weekend when I'm not on call. Other than some annoying trivial internal changes, the biggest reason this port was delayed was that Mozilla changed most of their legacy NSPR booleans (viz., PR_TRUE, PR_FALSE and the PRBool type) to C++ booleans (viz., garden variety true and false). This invalidated around two-thirds of our patch sets and required a lot of manual adjustment. There was also a bug in plain methodjit that this unearthed and yielded several days of fruitless rooting around in the code until I found a working solution earlier today. The tracejit seems to basically work, but I won't be able to fully test it until I get opt builds running, so I have not made a decision about whether people will be forced to use JM+TI in this release (if tracejit has minor problems, I will try to fix them; if it's unacceptably crippled by Mozilla's type inference changes, however, it's probably not worth repairing). I have decided that we will use methodjit for the chrome, because this will cut back on memory and the chrome code is obviously not changing; the tracejit decision relates specifically to Web content.

Once 10 is kicked out to the unwashed masses, development becomes bifurcated. Unlike the regular ESR, which will only get high-level security and stability fixes much as the moribund 3.6 gets now, our stable branch (based on the 10 ESR) will get other fixes and possibly even new minor features. Most users will get this release and receive point updates to it, which should be reassuring to our change-averse general audience. If a major feature needs to be backported, there will be a regular beta-and-RC cycle.

Development of the main Firefox channel will still continue in the background on the unstable branch. Let's make this clear now for you pedants in the audience: the unstable branch is not intended to make release-quality builds, just betas and test builds. There will almost certainly be bugs and minor ones will not be fixed on any particular timetable; the point of the unstable branch is simply to keep the port viable in a general sense (and to give me and the other contributors a well-deserved break). Only beta builds will emerge on the unstable branch, not RCs. I may sit out 11 to give myself a break, and pick up with 12.

The next scheduled ESR will be Firefox 17. I think it's unlikely we get that far, but hey, I said we were dead in Firefox 5 and Tobias got the linker working; I said we were dead by Firefox 11 and Ben showed up with the macroassembler. So don't rely on my picks for the NFL postseason if you want to keep your money. If we make it to Fx16, then Fx16 will get a regular beta-and-RC cycle, and the stable branch will move to 16 and then settle again on 17. It would be a miracle if we made it to Firefox 24, though (it's doubtful Mozilla would still even support 10.6 by then, and we're not going to make a "Lionized" TenFourFox because that would make me nauseous), but we would still do security updates, of course.

There are a few other things I'd like you guys to think about. I have had some internal discussions with Mozilla and TenFourFox is currently their draft recommendation for Power Mac and 10.4 users still on 3.6 (always subject to change, of course, but this seems like their intent). Right now we piggyback on SUMO, Mozilla's support system, but this doesn't seem fair when Mozilla won't support PowerPC at all. Instead, we're going to need to start up our own user support and triage network like I already have set up for Classilla ("Report-A-Bug"), just on a much larger scale. I'm soliciting for someone or a group of someones to head up triaging user reports and helping support the influx of new users we will likely receive, translating user reports into bug reports as appropriate. Please E-mail me or nominate yourself in the comments. You will get free beer if we ever find a bar that would serve our PowerPC-using riffraff kind.

The second thing I'd like people to consider is what to backport in case we don't make it to Firefox 17 (or when we don't make it to Firefox 24), i.e., when we drop to feature parity. We would need to implement important CSS and layout features from later Mozilla releases to keep the browser core reasonably current, possibly new JavaScript features, and definitely some important extension-like functionality to incorporate into the interface and maintain ourselves (the QTE, adblock along the lines of Camino's, user agent switching to mimic later browsers, etc.). This is not a Christmas list and Christmas has already left the building; it is a "need to have or we lose significant functionality" list. I'm not soliciting for this list yet because we're still at source parity for the time being. If it looks like we fall off the wagon, we'll need to powwow.

I'm shooting for 10 beta next week. I'll post if there will be a significant delay.