Sitting at this end of the calendar, 2009 seems like quite a long year; I’m exhausted, and I hope 2010 will be less of a marathon. 2009 was, however, still a good year for Camino, and that is what my annual look back is all about.
- First and foremost, we released Camino 2, a significant new release with lots of great new features like Tab Overview, phishing and malware protection, drag-and-drop rearranging of tabs, Growl support, and new AppleScript features. As with all community projects, it took longer than anticipated, but based on the very positive reaction, it was well worth the wait.
- Stuart Morgan fixed the most bugs, while Sean Murphy wrote three major new features; Jeff Dlouhy, Christopher Henderson, and Ilya Sherman also contributed major features to Camino 2.
- Our localization teams stayed busy, so the Multilingual edition of Camino 2.0.x currently ships with 15 languages.
- In conjunction with the Camino 2 release, we rolled out a redesign of caminobrowser.org. Thanks to our friends at Clearleft for the design work, Samuel Sidler for implementing the redesign, and Philippe Wittenbergh for helping to polish the rough edges afterwards.
- While our focus was on Camino 2, we continued to release security and stability updates for Camino 1.6 throughout the year, and beginning in the summer we started landing code for what will become Camino 2.1.
- Dan Weber was our Google Summer of Code student in 2009, working on enhancing the location bar. Over the course of the summer, Dan implemented a new look for the autocomplete window as well as extending autocompletion to include URLs and titles of both bookmarks and history items (fixing a couple of the oldest remaining Camino bugs in the process). Check out a nightly build to see his work in action.
- Our hard-working localization teams added two new languages this year, Slovenian and Turkish, and revived two translations, Chinese (Simplified) and Danish that have been missing for several major releases. Sadly, a few languages didn’t make the jump to Camino 2, so if Camino is not currently available in your language, drop by the caminol10n project website, join the mailing list, and learn how you can help!
I think that about wraps up the high points of the year, in a little briefer fashion than years past. Thanks to everyone who was a part of the Camino community in 2009—developers, testers, localizers, and users—for a great year! We’re always looking for new contributors, so if you’d like to help make Camino even better, there are many ways you can help out in the coming year. In the meantime, enjoy Camino 2, Happy New Year, and welcome to 2010!
This is a rather late reminder of the “pool” for the 2010 installment of the annual “we break our site for your browser when the new year rolls around” broken browser-sniffing contest (2010 Gecko browsers will be available in about 28 hours from now).
As I noted in January, the “three-peat” is Yahoo!’s to lose, although there was some talk last January of Yahoo! actually doing away with their date checking.
Get your picks in now for both the site/company that will break and the reporter of the Tech Evangelism bug who notices said site/company. (For the record, my picks are Yahoo! and Philippe Wittenbergh.) 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!
John Gruber points out a post by Basil Safwat that defends Google Chrome’s incorrect placement of the tab close button on Mac OS X. Safwat’s defense of the button is based on some nifty optimizations that Google’s engineers have made to their tab resizing behavior, such that users can continually hover in a single spot and close a large number of tabs with impunity, whether users are closing tabs from the right side of the tab bar or from the left side (see Safwat’s screenshots, if you haven’t already read his detailed analysis).
Like the old fixed-on-the-right-edge-of-the-tab-bar tab close button found in Mozilla and early versions of Firefox, and still seen today in SeaMonkey, I find this behavior very puzzling (actually, I found the Mozilla/Firefox/SeaMonkey version infuriating as well, since when I was mousing, I had to mouse over to the right edge of the window to a close any tab) and am surprised no one has questioned optimizing for it. That is, what is the use-case for serially closing a number of tabs—but not all of the tabs in a window—within seconds of each other, such that delaying the resizing of remaining tabs and the incorrect positioning of the close button on the tab are required? When I open lots of tabs, I typically handle them one by one, closing each when I’m done with it (often opening new ones in the process), and my cursor almost certainly won’t be sitting still in the same place as I interact with and process a series of tabs. Conversely, when I’m going to declare tab bankruptcy, there’s a great close button on the left side of my window to get rid of everything in a single click (well, two, since I have Camino warn me when closing a window full of tabs, but you get the idea), saving myself however many clicks would be required to close each tab individually, immediately after one another. I’m sure now and again I’ve accumulated a small number of throw-away tabs, but it’s never happened frequently enough that I’ve wondered if there were something we could change in Camino to make serial tab closing with the mouse more efficient.
When Firefox moved the close button off of the tab bar and on to individual tabs where it belonged, there were certainly complaints from adherents of the fixed-position button, but their arguments, to the best of my recollection of those long-passed days, were simply “the fixed button makes it easy to close a bunch of tabs at once,” without any explanation of how or when or why those users got themselves into a situation where they needed to close a number of tabs, but not all of them, right after each other.
It’s curious; why put so much effort into optimizing tab resizing after close and so flagrantly violate a cardinal rule of the Mac OS X UI grammar (in Gruber’s terms) that even the notoriously un-Mac-like Opera gets correct, to promote such a seemingly obscure set of browsing habits?
Looking back, it appears that the last regular Camino update was in early August, nearly four months ago! As you’ve no doubt noticed, Camino work did proceed, and if for some reason you hadn’t noticed, I’ll let you know that we shipped three security and stability updates (Camino 1.6.9, 1.6.10, and 2.0.1), one milestone (Camino 2.0 Beta 4), and one major release (Camino 2) since the last update. We also launched a new website redesign, brought the total number of languages in the multilingual edition of Camino 2.0.1 to 15 with the return of Polish, and have attempted to keep up with all the comments (overwhelmingly positive; thank you!) and bug reports we’ve gotten since the release of Camino 2—all the while battling illnesses and holidays. Herewith a brief update on the smaller details of the past week or so.
- Stuart Morgan handled the major Camino code changes for 2.0.1. He got Mac OS X 10.6 and the Help menu talking again in non-English localizations, and he hooked up support for collecting emails in the Camino Crash Reporter (once email addresses are available for authorized users of crash-stats, we’ll be able to contact you for more information about your crashes when we need your help).
- Christopher Henderson wrote a patch to make the about:config context menu start working, which is handy now that we officially acknowledge that about:config exists. He has also been working on some history-related changes and on implementing some missing bits in
CocoaPromptService that the about:config context menu wants to use.
- Chris Lawson gave Christopher’s patch a review, and he also began working through our backlog of unconfirmed bugs, following up on those that haven’t seen activity for a while.
- Samuel Sidler and Philippe Wittenbergh have been polishing some of the slightly-rough edges of the new website design and doing their usual parts to help with bug triage.
- With the release work for 2.0.1 out of the way, I’ve also joined in on the website polishing and bug triaging. Mostly, though, I feel like the sprint to 2.0 and then 2.0.1 is finally done, so I can take a moment and breathe.
That’s it for now; we’re slowly getting back in gear for the road to Camino 2.1, but the number of exciting changes will probably be light until after the new year.
If you’re reading this, it means that yet another major version of Camino is now in the wild. Today we released Camino 2 (codenamed ☢, because our first choice of “kittens” didn’t have a Unicode glyph) after over a year in development. There are a number of major architectural changes under the hood that should make your overall browsing experience much better, and on top of that we’ve added a number of exciting new features. It has, once again, been a long(er-than-expected) journey, but we’re very proud of all the work we’ve put into Camino 2 and are pleased to offer you a new stable release.
The road to Camino 2 began in April of 2008 when we wrapped up work on Camino 1.6, although we had been performing architectural maintenance and related work to keep up with Gecko 1.9 changes since late 2007 (and some of the changes in Gecko itself were made all the way back in 2005, after the
MOZILLA_1_8_BRANCH was cut on August 12, 2005). Over the last year and a half, we’ve fixed more than 450 “bugs” (problems or new features), and 16 different people contributed patches for this release (Stuart Morgan again led the way with 119 fixes). Sean Murphy implemented three major features this release (tab dragging, phishing and malware protection, and rewritten Full Keyboard Access support in the browser window), and Christopher Henderson and Ilya Sherman showed up to implement full content zoom and Growl notifications for downloads, respectively, and stuck around to fix over four dozen other bugs between them. Big thanks also to the one-third of that list of patch contributors who aren’t regular Camino developers; every little fix helps make Camino a better browser.
In some ways Camino 2 isn’t the revolutionary release we hoped it would be when we wrapped up Camino 1.6, but it’s still a vast improvement over Camino 1.6 and a triumph for an all-volunteer, all-free-time development team in today’s world of corporate-sponsored browsers.
Thanks to our hard-working localization teams, Camino 2 is available today in US English and 13 other languages, with Polish expected to join that list as soon as our Polish localizer’s Mac is repaired. Sadly, we had a few languages that shipped in Camino 1.6 disappear on us, so if your language is missing, please stop by the caminol10n mailing list and see how you can help bring these localizations back. (As I mentioned earlier this year, the work doesn’t require much specialized computer/software knowledge; you and a friend can bring Camino to thousands of users in your language! For Camino 2, new contributors successfully revived the Danish localization, which was in Camino 1.0 but disappeared from Camino 1.5.)
This year I again went to bed the night before release while fearless webmaster Samuel Sidler stayed up putting the finishing touches on the home page, the Features page, and implementing the new website design from the folks at Clearleft. One of these years both Sam and I are going to get a full night’s sleep before a major release, but this was not to be that year. Aside from a few things here and there, it seems like the website and webserver bits went more smoothly this release than with 1.6.
What’s next? Those of us who have been working on the website and release details for the past month or so are going to take a little rest. Parts of the development team, which wrapped up development with a late-October push, are already starting to work on new features for Camino 2.1. Nightly builds already include Dan Weber’s 2009 Summer of Code work on location bar autocomplete, and we have some early plans for other features in Camino 2.1 (we’re always looking for contributors, so if you’re interested in helping make a great Mac browser, stop by the Contribute page or find us on irc).
In the meantime, enjoy Camino 2.0 and let us know what you think!
Many of you might have noticed that, after upgrading to Mac OS X 10.6.2, Camino 2.0b4, Camino 2.0rc1, or Camino 2.0.1pre/2.1a1pre nightly builds have started crashing on launch or shortly after launch, perhaps as the first page was loading. (Some of you may have noticed these crashes ever since Mac OS X 10.6 arrived, but the font changes in Mac OS X 10.6.2 seem to have made the crashes much more widespread.) You might even be one of the people who have submitted one of these crash reports.
I have some good news and some bad news about these crashes. The good news is that we’ve been looking at the problem for a while now, and Mozilla’s font gurus, John Daggett and Jonathan Kew have a couple of theories about the cause of the crashes (probably Mac OS X font cache corruption, yay! ). In addition, we generally know how individuals can “fix” the cause of the crashes on their own Macs.
The bad news is that the individual “fix” so effective that we aren’t currently in contact with anyone who is still experiencing this problem, and reversing the “fix” doesn’t cause the crash to reappear. This makes it much more difficult to determine what exactly is wrong and to find the best way to fix the Mozilla code to make whatever the underlying problem is not crash Camino, now or in the future, for everyone.
If you’re currently experiencing this crash, we could use your help. There are questions in need of some answers, and we’ll probably be able to generate some test builds (to log additional information and eventually to test proposed fixes) soon. Please comment in bug 514114 if you’re seeing this crash. (If you can’t get Camino to launch in order to check about:crashes for your crash ids, you can open the Camino inside the Breakpad folder inside the Library folder in your users’s Home folder and look for files with names in the format of
CrashID=bp-0c24401b-93b6-4f7e-bcf7-8e4062091108.dmp; paste the
bp-0c24401b-93b6-4f7e-bcf7-8e4062091108 part into the search field on crash-stats to find your report.)
Finally, if you just want to make the problem go away and can’t help us track down the cause of the crash, you should open Font Book, check for and resolve any duplicate fonts (in the menu), and validate all of your fonts, removing any ones that Font Book flags as having problems (in the menu). You may also need to restart your Mac after removing duplicate and corrupted fonts.
Thanks for your help investigating this crash; we hope we’ll soon be able to make Camino stop crashing for everyone who is, or will be, experiencing this problem on Mac OS X 10.6.
Update (2009-11-17): John came up with a patch that should fix the crash, and it was reviewed and approved this evening. The fix should appear in tomorrow’s (2009-11-18) Camino 2.0.1pre, 2.1a1pre, and Firefox 3.0.16pre nightly builds.
As we move ever-closer to the release of Camino 2, I wanted to revisit the subject of crash reporting. A few years ago, I wrote about crash reporting and how to help fight crashes with Talkback, our decrepit crash-reporting system from the early years of this century. I realized a few months ago that if you started using Camino around or after the release of Camino 1.0, there’s a good chance you’ve never seen Talkback, since part of its decrepit nature was its PPC-only binary, and Camino 1.0 coincided with the beginning of the transition to Intel-based Macs. Now that Camino 2 includes modern crash reporting based on Google Breakpad (tip o’ the hat to mento for bootstrapping modern open-source crash reporting), users with Intel Macs may be experiencing Camino crash reporting for the first time, so it’s a good time to revisit what you should do to help us find and fix crashing bugs.
Like Talkback before it, the Breakpad-based Camino Crash Reporter collects data about your crash and, when you agree, sends the data to Mozilla servers, where we (the Camino team) get to see the information in aggregate (and non-personal information in individual crash incidents).
How crash reporting works in Camino 2
If Camino crashes, the Camino Crash Reporter pops up and asks you to add a comment and then to report the crash:
When you restart Camino, you can visit about:crashes to find the report ID for the crash you just experienced and even see the processed report.
The about:crashes page contains a list of report IDs for crash reports you’ve submitted successfully to Mozilla’s crash collection servers. If you click on the report ID, you can see the processed report for your crash. Not all reports are processed immediately, so you may see a “processing” screen at first:
Once processing is complete, you can see the full report for your incident on crash-stats:
How you can improve the chances of your crash being fixed (and how to improve your crash report)
We hope that you’ll never have to use the new crash reporting in Camino 2, but if you do, following these simple steps will make your report as useful as possible and improve the chances of the crash you experienced getting fixed.
When you experience a crash, the most important thing you can do is to allow the Camino Crash Reporter to submit your report to us. If we don’t know a crash is happening, there is a zero percent chance that we will be able to fix it (if you’re happy seeing the same crash over and over, then don’t feel the need to submit a crash report ). Many times we’re able to discover and fix crashes just from the aggregate data generated from users submitting crash reports to us.
Second, when you submit your report, please add a comment! We know that crashing is frustrating and disrupting, and it is tempting to just press Submit (or even Cancel) and get back to what you were doing. However, while the computer-generated data that is submitted in the crash report tells us “what” is happening, it often is insufficient to allow us to fix the problem, and comments can help bridge that gap. When you add a comment, please be reasonably descriptive when telling us what actions you might have performed just before Camino crashed. As you can see in the sample crash above, I listed a number of specific steps that I performed just before Camino crashed.
In addition to providing a comment, if you are comfortable providing the URL you were viewing when Camino crashed (and you know, or can look up in History, what that URL was), include it in your comment, too. While Camino attempts to collect the URL you were on when Camino crashed, the URL is not displayed with your crash report for privacy reasons and is not readily available to anyone. As I mentioned several years ago, a good comment and a URL can be the difference between a frustrating crash and a fix. Unfortunately, only a few reports out of every hundred currently include a comment, so there are many opportunities to understand and fix crashes that are currently being lost.
Finally, if you experience what you think might be the same crash, over and over—either whenever you visit a certain site you crash, or performing the same series of actions on a variety of sites leads to a crash—please file a bug. While aggregate crash data can help us discover crashes, especially those that don’t otherwise seem to have a pattern, this data is no substitute for a bug report from someone who is actually seeing the crash frequently. Sometimes specific crashes can still get lost in aggregate data, and filing a bug report on a crash that’s plaguing you can bring it to our attention.
When you file your bug report, please be sure to include the report IDs of incidents of this crash. To get the report ID, type about:crashes in Camino’s location bar and press Return. Camino will display a list of crash reports you have submitted and their corresponding report IDs (a long string of letters and numbers). Copy the crash report ID corresponding to the crash you are reporting and paste the ID into your bug report, adding bp- to the beginning of the pasted string. For example, a crash report id of
0c24401b-93b6-4f7e-bcf7-8e4062091108 should become
bp-0c24401b-93b6-4f7e-bcf7-8e4062091108 in your bug report, and Bugzilla will then link that string to your crash report. (Please do not paste entire crash reports into the “Comments” field of the bug report.) Then, please be willing to answer questions and perform some tests as we work to understand and fix the crash you’ve reported in the bug.
Finally, when filing a bug or making a comment in a crash report, please don’t berate us. We know you’re upset that Camino crashed on you, and we’re just as upset, but yelling at us doesn’t help. Also, since at least one-third of crashes we see are caused by third-party software (for example, browser plug-ins, third-party hacks, or even fragile parts of Mac OS X itself), you might be yelling at the wrong party anyway.
- Any crash report you submit is better than no report at all, so please always allow Camino Crash Reporter to do its job.
- The more information you provide in your crash report (comment or URL), the more useful your report is to the developers.
- For crashes you can reproduce or see over and over, reports filed with Camino Crash Reporter are no substitute for an actual bug report (with crash report IDs).
- Please be polite and civil in your comments and bug reports; we’re all working towards the same goal here (Camino not crashing on you).
All of which is a long way of saying “you could be the key to fixing the crash that is annoying you.”
Please enjoy Camino 2 (due out “real soon now”), and don’t fear the Camino Crash Reporter; it’s only trying to help.
Taking another break from working on tasks for the Camino 2 release, I wanted to write a little bit about our amazing team of localizers tonight. As if someone was reading my mind, Christopher Henderson showed us this tweet he came across tonight.
Camino 2 is likely going to ship in English and 13 other languages (attentive readers will note that this is down by two from the number of languages in Camino 1.6.10, but still three more than shipped in the initial Camino 1.6 release), all translated by our volunteer localizers from the caminol10n project. New to Camino 2 will be Danish (which last appeared in the Camino 1.0 series) and Turkish, making its debut as a Camino localization.
The story of Danish in Camino 2 is particularly worth telling. At the end of September, about two weeks after we released Camino 2.0 Beta 4, Danish Camino user Allan Nyholm Nielsen posted a message in the Camino discussion forum asking why Camino 1.6 was localized in Swedish and Norwegian but not Danish, and whether Camino 2 would include a Danish translation. A member of the Camino development team replied that our localizations are all produced by volunteers and that while there had been a Danish localization in Camino 1.0.x and some work had been done for Camino 1.5, the leader of that team disappeared and the translation for 1.5 was never finished. We also pointed Allan to the caminol10n project (and to another Danish Camino user on the forum, David Munch, who could possibly help) and urged him to think about reviving the Danish translation.
The very next day, Allan had posted to the caminol10n mailing list (and back in the Camino discussion forum) stating that he had signed up and had gotten started. Two weeks after that, Allan posted a message stating that he had essentially completed the translation of Camino 2 into Danish, and, after a week of polishing the translation, he reported he had the complete translation ready.
In three weeks, we went from having no Danish translation and only an interested user who had never done any Mac OS X application localization to having a complete, peer-reviewed Danish localization for Camino 2.0! Congratulations to Allan and David on this achievement.
If you would like to see Camino in your language, you too can make it a reality. While not every language has a localization of an older version of Camino available to jump-start the process (there are a dozen languages that have shipped in past Camino versions that will not be in Camino 2.0, however), and while some teams take longer to complete a translation than others, you can still get started today and perhaps be ready to include your language in Camino 2.0.1 or 2.0.2. There are a few, relatively simple, specialized tools to learn, but for the most part all you need to know is English and your own language. There might even be other speakers of your language already interested in helping, and the existing Camino translators are knowledgeable and can help you get started with the tools.
The Danish experience is not an isolated case, either; during the Camino 1.6.x series, we added three new languages, and one of them was complete in a matter of weeks (one took a month or so, and the third we learned about only when it was already complete).
If your language is already included in Camino, be sure to thank the members of your language’s translation team and ask them if there is any way you can help; existing teams are usually looking for new members, too, to help spread the workload.
Finally, it is with sadness that I report that Catalan, Czech, Polish, and Portuguese (pt-BR) will be missing from Camino 2.0, so if you are a Camino user who speaks one of those languages, now is the time for you to get involved. Register with the caminol10n project, join the mailing list, and bring your language back to Camino.
Just a very brief post here tonight, to come up for air and to mark an occasion; I have a large backlog of things to write about in the near future, and also a lot more work to do.
I realized tonight that in the year that I have been handling the “build” side of Camino’s build and release process (at first sharing duties with the illustrious Mark Mentovai, and then on my own), I’ve produced builds for a bunch of releases: five Camino 2 milestones and five Camino 1.6.x security and stability releases (with at least one respin in the mix). However, I had never been responsible for the build process for a major release, for the new version that’s all shiny, the culmination of the entire team’s hard work, and the build that’s tested and reviewed by the world. Since 2006 (and Camino 1.0), Mark had always handled that. Tonight, though, I felt the weight of tagging on my shoulders.
Which is a long, rambling, nostalgic way of saying that we now have a Camino 2 release candidate (note to the press and other interested parties: release candidate; Camino 2 is not out yet) for our community to hammer on, with special thanks to Stuart Morgan for fixing a dozen or so of our blockers and wanted/pseudo-blockers in the past two weeks and to Mark for the ninetieth-minute superreview on the very last patch.
I’ll have more to say about Camino 2 in the coming days, and the release will be here before you know it, but for now I’m just going to mark this milestone, point everyone to the usual places, take off my build engineer’s cap, and go to sleep.
Today’s Camino 2 nightly builds enable tabs by default; that is, ⌘-clicking a link now opens that link in a new tab rather than a new window. After all, we’ve been adding all sorts of new tab-related features since Camino 1.0 (and especially over the past few releases)—more tabs per window, better overflow tab management, the ability to redirect links that want to open new windows into new tabs (“single-window mode”), better AppleScript access to tabs, a scrolling tab bar, the ability to rearrange tabs by drag and drop, and tab overview (“Tabsposé”)—so with all this development focus, it was high time that tabbed browsing became the default browsing mode in Camino.1
Moreover, as many other browsers have adopted tabbed browsing as the default mode of operation, users expect it to “just work” and potential switchers are sometimes confused by the fact that they have to open Preferences to allow ⌘-clicks to create new tabs. Users who prefer that ⌘-click open links in new windows are no doubt going to be a bit disappointed, but we believe this change benefits the majority of our users and potential users. If you’re strictly a window user, please give the new setting a try for a little bit; your may find your feelings have changed as tabbed browsing has become more powerful (I can still remember years ago swearing I’d never use tabs, but here I am [ab]using them). However, if tabs still aren’t for you, it’s easy to disable this setting by opening the Tabs pane of Camino’s Preferences and unchecking “Links opened with ⌘-click.”
As a brief house-keeping note, you may have noticed a lack of regular Camino development updates here over the past couple of months; August was an extraordinarily busy month for me, and September was occupied by the release process for Camino 2.0 Beta 4 and Camino 1.6.10. Fear not, however; Camino development has continued to make great progress, and we’re in the final stretch to Camino 2! I can’t promise when I’ll be able to return to regular posting of updates, but rest assured we are working steadily—and in the meantime, join us in having a Happy Tabs Day!
1 Amazingly, Camino isn’t the last Mac browser to default to ⌘-click opening links in new tabs; of the long-standing Mac browsers, both iCab and SeaMonkey still default to ⌘-click opening new windows. ↩