08.25.11
Dear Steve…
Best wishes for the next stage of your journey.
…And thanks for all the Macs.
07.11.11
Code complete for Camino 2.1 Beta 1
It’s been a long time since I’ve made a Camino-related post (due to my new time constraints), but I wanted to pass along some good news quickly.
Sunday night Stuart and I landed the last two bugs we’d been waiting on for Camino 2.1 Beta 1, so our final preview is now code complete. There is still some release note- and website-related work to be done before we can build and ship Beta 1, but we’re close enough that you can start counting down the days!
03.29.11
Camino crashes after upgrading to Mac OS X 10.6.7
A number of users have been reporting persistent, random Camino crashes following their upgrade to Mac OS X 10.6.7 (which was coincidentally released about the same time as Camino 2.0.7, causing much confusion over the source of the new crashes). Mac OS X 10.6.7 contained a large number of changes to font handling (the “ATS” and “CoreText” items) that, in some cases, rather than preventing font-related crashes, have caused new ones.
In all of the cases we have successfully debugged so far, users have had corrupt or invalid fonts which have, in conjunction with the font handling changes in Mac OS X 10.6.7, caused Camino to crash. Luckily, there is a relatively simple series of steps you can take to restore stability to your OS and prevent Camino from crashing:
- Validate your fonts using Font Book; remove or disable all fonts with errors or warnings, as well as any duplicate fonts.
- Restart your Mac in Safe Mode to clear the OS font caches (which contain data for the corrupt or invalid and duplicate fonts you removed/disabled in step 1).
- Restart your Mac normally, and Camino should no longer crash from these font-related crashes while browsing.
If Camino still crashes after removing corrupt, invalid, and duplicate fonts and restarting in Safe Mode, please post in the support forum so that everyone can help further debug your problem (and please include links to crash reports you’ve submitted for these crashes).
Special thanks to Philippe Wittenbergh for his always-expert memory of the steps necessary to resolve font cache corruption.
02.19.11
Channeling smfr
In the early days of my involvement with the Camino Project, senior developer Simon Fraser (smfr on IRC) had a way of fixing bugs that left me mesmerized. Simon would get home from work, hop on IRC, ask around for a (usually thorny) bug that needed fixing, and in an hour or so would have fixed not only that bug but also two or three related ones as well (while still managing to answer questions from less-experienced members of our development team). We were fond of those “smfr hat tricks,” as we called them, because they were almost always giant leaps on the road to the then-elusive Camino 1.0.
Lately I’ve come to understand the rationale behind those hat tricks; after digging through a bunch of code to understand it and be able to fix the bug you’re after, it makes sense to go ahead and tackle other bugs in the same code. So, recently, I’ve been channeling smfr, fixing sets of bugs in our save code, in our HTML bookmarks export code, and in our pasteboard and local-file-decoding code, among others. They’re not smfr-level fixes, but they are fixes that have removed many longstanding bugs (and, in the case of HTML bookmarks export, improved the ability of that export to serve as a backup without significant data loss). And, in the end, they keep moving Camino forward, and that’s what really matters.
01.28.11
Sourcestamp file format changed on mozilla-central
Overview
Beginning with yesterday’s (January 27th) nightlies, the sourcestamp file ($product-$version-$language-$platform.txt, e.g. firefox-4.0b11pre.en-US.mac.txt) produced alongside every build changed formats.
History
Since its introduction in February of last year, the sourcestamp file had been a single line with two space-delimited values, the build ID and the repository revision/changeset (in theory always the revision of the platform repository, e.g. mozilla-central, but in practice instead using the comm-* revision in the comm-* repositories due to differences in the way the two repositories were set up):
20110126030333 e0fc18b3bc41
Changes
Unfortunately, this old format was only fully useful for Firefox, since all other mozilla.org products are built from multiple repositories and would need to list two (or more) revisions/changesets. So in bug 549958 I changed the sourcestamp file format to be a multi-line file, where the first two lines are always the build ID and the platform changeset URL (regardless of which repository an app is built from):
20110127030333
http://hg.mozilla.org/mozilla-central/rev/b5314bc1a926
At the time I wrote the patch, the only known consumer of the sourcestamp file was Socorro. With the recent migration, Socorro’s code to handle both sourcestamp file formats was deployed, so we could finally change the file format; this happened Wednesday night.
There have been a couple of unexpected breakages as a result, for which I apologize. If you have a tool that consumes the sourcestamp file (or code that uses the MOZ_SOURCE_STAMP variable that was defined and exported by mozilla-central), please check to make sure it can handle the new format in addition to the old one and the output is still as expected.
mozilla-1.9.2 and mozilla-1.9.1
This change is currently only in place on mozilla-central; however, I intend to try to land this change on the branches for the the release cycle following (the soon-to-be-released) Gecko 1.9.2.14/1.9.1.16. Doing so will ensure that all branches are in sync and that tools that only work with “current builds” will not have to maintain code to handle both formats indefinitely; you can follow bug 549958 to keep abreast of branch landings.
New Goodies for Multi-Repository Apps
For applications that use multiple repositories (mozilla-central and an app repository, for instance), it’s now possible to add the app repository’s revision (or app repositories’ revisions) to the sourcestamp file.
If you’re already calculating your application’s source stamp and repository (for instance, for inclusion in application.ini) and exporting those variables, you need only make one small change to your app’s installer/Makefile.in:
# Add our own changeset information to the MOZ_SOURCESTAMP_FILE make-sourcestamp-file:: @echo "$(APP_SOURCE_REPO)/rev/$(APP_SOURCE_STAMP)" >> $(MOZ_SOURCESTAMP_FILE)
If your application isn’t currently calculating these values, you can copy the MOZ_SOURCE_STAMP and MOZ_SOURCE_REPO rules from toolkit/mozapps/installer/package-name.mk, change the variable names, and substitute the appropriate directory for $(MOZILLA_DIR) in order to calculate the correct values (placing the rules in an appropriate Makefile and exporting the variables as required).
Were Thunderbird, for example, to add this information, its sourcestamp file would look like this:
20110128045924
http://hg.mozilla.org/mozilla-central/rev/a84260b56b08
http://hg.mozilla.org/comm-central/rev/0f313f7b192e
With these changes, your QA team will be able to regression-hunt through old builds and easily know the revisions of all repositories in question before they even download the build!
01.24.11
Why Wevah Is Awesome
(Or at least one reason why.)
Wevah stopped by #camino on Sunday to help Sam fix a server migration-related website bug we’d just discovered. Before the day was out, not only had Wevah fixed that site bug (Regex Jesus to the rescue!), but a second one as well.
Even better, he fixed a three-plus-year-old “blocker” Colloquy bug 10 minutes after I mentioned the bug to him (it’s almost as if he scares bugs into fixing themselves).
The best part of it all is that Wevah’s awesomeness rubs off on everyone around him; after Wevah finished his bug-fixing spree, I looked again at a bug that had been stumping me for some time (Wevah had actually given me the hint that allowed me to fix said bug’s predecessor) and was then able to re-arrange some code and get things working.
Fixing bugs is never more fun than when Wevah is around; everyone should be so lucky to work with Wevah on a project sometime.
And that, my friends, is why Wevah is awesome!
01.12.11
Camino 2011 Week 1
As I mentioned previously, I don’t plan to try to continue regular weekly updates this year (though Sam plans to begin once again producing regular updates, in the old Camino Update style, it seems). However, I do plan to post irregular updates as warranted, and although this post is titled in the old style, it is firmly in the new “irregular updates as warranted” camp.
Camino started 2011 off with a bang, as Stuart Morgan landed both of his large, long-awaited patches: the history loading rewrite and the autocomplete performance rewrite (the latter begun originally by Dan Weber). As a result, typing in the location bar is now smooth as silk once again, and the autocomplete results are a lot more awesome. If the poor typing performance in the location bar has kept you away from nightly builds, you can make the jump now without fear (as always when switching to nightlies, be sure to make a backup of your profile first). Stuart also debugged, fixed, and landed his patch for a focus bug that prevented form fields on some pages (such as Google web applications) from being focused, and he dusted off another old Dan Weber patch to partition off the feed and security icons at the far end of the location bar.
Returning after the holidays, I landed Chris Peterson’s patch to finally make the Downloads window use the proper selection color. In addition, I started work on what appeared at first to be a simple follow-up to that patch, a fix to make the selection color behave properly when the Downloads window was in the background. (Alas, it did not end up being simple at all, but with some help from Ilya Sherman and Stuart, I completed my first major code refactoring, and I was able to land the patch late last night.) I also pushed a few website changes and started working on the release-wrangling tasks leading up to Camino 2.1 Alpha 1.
Chris Lawson initiated our first major CLOSEME sweep of old unconfirmed bugs of the year, setting us up to close many abandoned bugs next weekend for a good start to the year.
In addition, we’ve been very happy to meet a few Camino users who are interested in helping with development and triage (perhaps it was a popular New Year’s resolution in the Camino community? 
). Regardless of the reason, as an all-volunteer project often limited by the human resources available to us, we’re always grateful for every contributor. If you’re interested in getting involved with Camino development or bug triage, feel free to stop by our IRC channel, let us know what your skills are, and find out how you can help. (Similarly, if you speak a language other than English and want to help with the localization of Camino, please visit the Camino Localization project’s website and subscribe to their mailing list to learn how you can help.)
And that’s it for the first week of 2011. I’m off to continue working on release-wrangling for Camino 2.1 Alpha 1, which we hope to have available soon. In the meantime, enjoy the improved autocomplete performance in the nightlies, and let us know if you find any lingering issues!
01.09.11
Camino 2010 in Review
For me, 2010 was an exhausting year, and that definitely bled through into my Camino involvement; I had less time to write, so there were fewer and more irregular status updates—and, while Camino Planet was malfunctioning, none at all—fewer forum posts, fewer bug cleanups, and generally less of a public face. As a result of the year, I ended up taking a fairly long hiatus for the holidays, and I’m trying not to jump back into things at full speed.
For Camino, 2010 was an interesting year, a year of many transitions. We had more changes in our teams than in past years, as Sam headed off to travel the world (and most of his responsibilities fell to others) and as successful careers took off for other contributors. Although 2010 was the first year since I began these years-in-review that we did not ship a major new version, we made many significant changes in the hectic first half of the year that laid the foundation for bigger and better things to come.
- We shipped five security and stability updates to Camino 2 during the year, including fixing several long-standing bugs; our localization teams continued to supply release notes and update descriptions for these updates in all 15 languages. We also released Camino 1.6.11, one final security and stability update for our Mac OS X 10.3.9 users.
- Camino 2 was a finalist for Best Independent Browser and Best Mac Browser in the 2010 About.com Reader’s Choice Awards (in the former category, Camino was the only browser nominated that didn’t run on Windows, and we finished second in the voting).
- Camino built across six different branches in the course of the year, from Gecko 1.8.1 (Camino 1.6.x) all the way to the latest, Gecko 1.9.3.
- In February, Christopher Henderson got Camino building on Gecko 1.9.1 (with some help from me, and from some earlier efforts by Philippe Wittenbergh and Kai Rune Mathisen to build newer Gecko versions).
- The very next week in February, Christopher got Camino building and running more-or-less as expected on Gecko 1.9.2, and I started producing the first of many experimental builds while we fixed lingering issues and worked on building “out-of-the-box” with that version of Gecko, a process that lasted until late May.
- Following up on the work to get Camino working on Gecko 1.9.2, in early June Stuart Morgan almost single-handedly got Camino building against mozilla-central (Gecko 1.9.3), before we were slammed into a brick wall of embedding-unfriendly code and massive Gecko platform changes that were taken after the platform had reached the beta stage! (Because of those issues and the focus by Mozilla platform developers on bugs related to Firefox 4, we put the mozilla-central experiment on hold and concentrated our efforts on the places that would bring the most benefit for our users.)
- Christopher also wrote a very significant patch that moved Camino from the old, creaky Mork history to the newer SQLite-based history backend; combined with 2009’s autocomplete rewrite and the move to Gecko 1.9.2, Camino finally became free of the trinity of Bad Old Mozilla Technologies (Mork, RDF, and XPFE).
- Camino development moved from CVS to Mercurial, and our volunteer development team adapted to the many changes brought by the new system. (Stuart learned his 1001st different version control system in service of Camino, and I learned about the wretched, buggy state of Mercurial’s CVS import tools, spending the better part of a month trying to coax a workable import out of that software.) In addition, I put together build automation for our new Gecko 1.9.2-based repository and nightlies.
- After getting nightlies based on Gecko 1.9.2, most of our attention during the year was on the lingering issues with the new (slower) history and autocomplete implementations, and to a lesser extent on focus regressions from the Gecko focus rewrite. This was an area where the strains and limitations of an all-volunteer project became evident in 2010, as many of us spent about half the year living with a slow location bar. Dan Weber started working on fixes early in the year, but he was pulled away by school and other things; Stuart picked up the work and, as time permitted, slowly iterated through what became a significant rewrite of both the autocomplete code and parts of the history user interface code. (The thoroughly-rewritten code, which landed in the first week of 2011, works very well, and everyone will see it in an alpha very soon.)
- Our “fun with tinderboxen” in 2010 was not nearly as traumatic as in past years. Although both of our 10.4 tinderboxen—our original Xserve, cb-xserve01, and our last PowerPC tinderbox, cb-minibinus01—went down for a several weeks during the year, both were resurrected successfully (although cb-minibinus01 came back running Mac OS X 10.5, which was not ideal, but better than losing our last PPC box entirely). In addition, at the beginning of the year, we brought a brand-new Xserve, cb-xserve04, online, which gives us some headroom for the future (in addition to producing our Camino 2.1 development nightly builds). While Sam did most of the work of setting up cb-xserve04, I handled the setup of the other two when they returned to us, leaving me fully versed in tinderbox setup.
- While Camino websites have been trouble-free for quite some time, Camino Planet did suffer an outage where it failed to update due to errors after a bizarre SSH outage on our server. Our major website project in the second half of the year involved moving to a newer, better-configured server (as our host was decommissioning our current one); Sam did most of the work on that project, and afterwards we were able to deploy a number of website changes that we had wanted to be able to do for some time. The other significant event in the website department was the introduction of Flash version checking (a joint effort from Stuart, Philippe, Sam, and me) on the welcome page shown after installing or upgrading Camino; the notifications have made a noticeable difference in ensuring Camino users are updating Flash to get that plug-in’s latest security and stability fixes.
- The composition of our development team was in flux again this year, reflecting the nature of a volunteer project. Many of those who carried Camino through 2009 and the Camino 2 release moved on to new jobs or lucrative careers as indie Mac/iOS developers, while others had to cut back commitments. In addition to Christopher’s and Stuart’s efforts mentioned above, highlights of our developer cadre included the following:
- Towards the end of 2010, Chris Peterson showed up and began fixing assorted bugs, mostly in the Downloads window and in our menu code (though he has additional patches in flight touching scarier stuff, like focus!).
- Sean Murphy (who contributed significant features to Camino 2) made a brief reappearance to update our gesture support for Gecko changes, and Ilya Sherman performed his first code reviews. Philippe Wittenbergh continued to keep us looking good with website fixes, new icons and images, updated CSS, and he even ventured into the realm of small code and Makefile fixes.
- Although Sam insisted that I be listed on the Programming team beginning with the Camino 1.6 release, I had never really felt like a “developer” previously (in addition to ad-blocking, I mostly touched project file changes and, after some tutelage by mento, various build system-related fixes). However, in 2010 I finally started producing fixes to our Cocoa/Objective-C code on a somewhat-regular basis; I learned a little more about debugging and began investigating and, where I could, fixing things that annoyed me! I also ended up fixing several bugs in Gecko that blocked our 1.9.2-based builds or were regressions, and I worked on extending a number of changeset-related Gecko build system features to work in cases where an application is built using code from multiple repositories (as is true for every Gecko-using application other than Firefox). So, in 2010 I learned (and forgot!) a good bit of Objective-C/Cocoa (and some Perl), and I finally felt like I could play a developer on TV. While I’ll never be able to have a large impact like writing new features or performing significant code surgery and refactoring as our Cocoa stalwarts do, I can still help by fixing some small things, in between my other responsibilities in build and release, website and documentation, and bug-minding. As we often say, every additional developer counts.
So there’s a belated look at the many highlights (and some “lowlights”) of Camino in 2010. Although sometimes it seems like less happened in 2010 than in years past, looking back on the year reveals many large changes; they were just sometimes slow to develop and often were not exciting, user-facing changes. Nevertheless, we find ourselves on the cusp of a great new Camino 2.1 Alpha as the new year opens!
Finally, I want to take a moment to extend thanks again to the entire Camino community: our developers, our testers, our localizers, our users—the folks posting in the forum, writing AppleScripts, and filing bugs; those who take time to blog, tweet, and make videos about Camino; and especially those who help out with user support and bug triage—and our friends. All of you make this great little browser possible, and we’re grateful for your contributions, your continued support, and your love for Camino. Here’s to a great 2011!
01.03.11
Camino Planet feed changing and other administrative notices
Just as a brief administrative update, following this post, Camino Planet will switch to pulling the feed that corresponds to my Software category, which includes additional topics such as open-source and other software issues and more general computing-related items. This harmonizes the feed at Camino Planet with what Planet Mozilla already consumes, as well as with the overall feel of Camino Planet.
In addition, I’ve talked with Sam about either sharing or having him take over the Camino update “responsibilities” this year, in order to provide more timely updates than I’ve been able to produce recently. (Edit: Look, he’s already posted the first one!)
Finally, my annual Camino Year-in-Review post is still coming (if only people would stop interrupting me!), so there is still that to look forward to before I possibly go radio-silent for a while.
12.30.10
Reminder: Year 2011 Bug Contest
This is a late (but not quite as late as last year!) reminder of the “pool” for the 2011 installment of the annual “we break our site for your browser when the new year rolls around” broken browser-sniffing contest (the first 2011 Gecko browsers will be available in about 54 hours from now).
Since perennial contender Yahoo! finally cleaned up its act last year, the 2010 dodo prize went to FCKEditor, the first winner that affected entire swaths of the web rather than just a single website or a collection of an organization’s websites. (FCKEditor is a WYSIWYG text editor implementation for web pages used by many websites and by common web applications/web-based software packages for creating and maintaining websites.)
However, I’m hopeful that, after so many years, this entire contest will soon go the way of the dodo. Between renewed efforts to remove the build date from the Gecko user-agent string, evangelism associated with the many user-agent string changes in Gecko 2.0, and simple exhaustion of the number of possible contenders (after six years, and with the tens place in the year having been filled with a new number last year for the first time since many websites were created), I’m (overly) optimistic that people’s regexps have finally been audited. 
Still, get your picks in now for both the site/company/piece of the “web software stack” that will break and the reporter of the Tech Evangelism bug who notices said site/company/piece of web software. No actual prizes will be awarded, but both winners will be recognized in a future entry in this journal.
And remember: only you can prevent bad browser-sniffing!