02.22.10
Posted in Camino at 9:50 pm by Smokey
Just a brief reminder that there are only two days of voting left for the 2010 About.com Reader’s Choice Awards.
Camino is a finalist in the Best Independent Browser category (as announced on the Camino Blog earlier this month), as well as in the Best Mac Browser category (which we didn’t know about until recently). In the Best Independent Browser category Camino is the sole Mac-only browser, while competitors in the Best Mac Browser category include most of the usual suspects.
Voting runs through February 24 (or perhaps midnight on February 25—in an unspecified time zone; all of the documentation is unclear!), so if you’re a Camino fan, you can vote in the Best Independent Browser and Best Mac Browser polls. (You can find all of the categories in the awards here and vote for your favorite websites and programs in other categories.)
Permalink
02.16.10
Posted in Camino at 1:24 am by Smokey
Just a quick update from the trenches on the “newer Gecko” project: I’m writing this post from a Camino 2.1a1pre based on Gecko 1.9.2.2pre (the same Gecko version used in Firefox 3.6.2pre nightly builds).
Last Monday, shortly after Christopher Henderson and I had produced working Gecko 1.9.1-based builds, he posted the first screenshots of a 1.9.2-based Camino. Over the following week, Christopher has debugged a couple of crashes, as well as the history-not-saving-across-sessions bug mentioned in the comments of the previous announcement. I fixed a few other build-related issues and hacked around a couple of smaller Gecko bugs, and Philippe Wittenbergh started working on polishing our custom CSS to handle the newer Gecko versions.
As a result of the week’s work, we now have available a Gecko 1.9.2-based Camino 2.1a1pre Universal build (with all the best warts of both) for further testing. Those of you who want to play along at home can build with this large patch (the CSS fixes are in additional patches in bug 545353). N.B. You should treat this build as highly experimental. It might eat all of the cheese in your house. Be sure to make a backup copy of your profile first.
We’d like nightly build users and other interested people to hammer on this build for a while to help us gauge the degree of bugginess; if the bugs we hear about seem manageable, we’ll focus our attention here. For the time being, please comment about specific problems on this thread in the forums.
Permalink
02.08.10
Posted in Camino, History at 1:49 am by Smokey
It has been some time since the last regular Camino development status update, but that doesn’t mean we haven’t been hard at work—it just means that I’ve been pretty busy with all sorts of things, and the status updates have been fairly low on my to-do list.
As I said, though, we’ve been working on all sorts of things so far this year. Dan Weber has been hard at work on patches for some of the most visible issues with the new autocomplete experience, and I landed the fix for the magically-reappearing autocomplete window tonight. Dan is also still working on improving the speed of autocomplete for large histories, though that patch is not yet ready. Chris Lawson has also been working on various and sundry other bugs, including changes to the Flashblock exceptions list so that pasting URLs into the field will work as users expect. Philippe Wittenbergh is hard at work polishing some of our toolbar icons.
Christopher Henderson has been working on a patch that moves our history off of Mork, which is both the sane thing to do and critical for moving forward to the new Mork-less world. As usual, I have been chasing down bugs here and there and wrangling patches to get ready for the upcoming 2.0.2 and 1.6.11 releases. We’ve also seen Alex Jones, who has been working off-and-on on supporting Mobile Me sync, again recently, though it sounds like Sync Services wants to do things in a manner that is not easily compatible with Camino’s bookmarks implementation. All in all, we’ve been fairly productive since the new year began.
Which brings us back to the title of this post and to this weekend’s developments. Late Saturday afternoon, I got a debug version of Camino to build, launch, and run using Gecko 1.9.1, and early Sunday evening I was able to make a static (i.e., distributable) build do the same thing. (Even better, Christopher Henderson was able to replicate my success.) This feat would not have been possible without all the hard work that Christopher put in for the aforementioned history migration, as well as a good bit of debugging and patching he did this weekend as we hit some unexpected code-change-related build failures. After applying those patches, I mostly deleted and added things to the project and waited for the next build failure. At the end of the day, though, Camino launches and runs, plays <audio> and <video> (with Ogg), and displays pages with @font-face (with raw TrueType fonts).
This doesn’t mean that we can turn around and release a version of Camino based on Gecko 1.9.1 (and there’s a very strong possibility we may not); for starters, there are a number of known regressions (including the loss of Find-As-You-Type), as well as possibly hundreds of other serious problems we haven’t discovered in our limited test browsing. Beyond that, the “build system” is not yet a system at all; it involves pulling mozilla-1.9.1 from hg, checking out Camino from cvs into mozilla/camino, and applying a large patch. But if you’re brave or crazy, you can try this at home now (and for those less brave or more sane, there’s an Intel-only build here that you can use to help us find other broken things. N.B. You should treat this build as highly experimental. It might eat all of the cheese in your house. It will eat your profile, so make a backup copy first).
(Update 9 Feb: The patch above now has all of the required parts of the history migration, which had been missing from the earlier patch.)
We also know (thanks to earlier attempts by Philippe Wittenbergh and Kai Rune Mathisen to build mozilla-central) that there are more serious code breakages in newer versions of Gecko, so this is only the beginning. In between other things the last few weeks, I’ve also been working on a new repository and fleshing out issues and solutions for the build system. There’s a long road ahead, and Camino 2.1 might be ready before we’ve gotten to the end of the road; we’ll have to see. However, as Christopher said on Saturday night, “it’s been a great day in Camino Land.”
Permalink
02.07.10
Posted in Camino, History at 11:21 pm by Smokey
FCKEditor!
This news is a bit old now (since it appeared briefly on Planet Mozilla the other day half-buried in a PR round-up, and since reader James reported it in a comment on January 21), but FCKEditor is the winner of the 2010 edition of the annual “we break our site for your browser when the new year rolls around” broken browser-sniffing contest.
If you use FCKEditor on a site and it doesn’t work with Firefox 3.6 or nightly builds of any Gecko browser built since January 1, you’re probably seeing the bug that won FCKEditor this year’s prize with a stunning upset of two-time defending champion Yahoo!
My gut feeling is that this new type of contest winner is much worse than the old “major site is broken” type, since there is no single point of contact for the fix (everyone who uses the affected versions of FCKEditor will have to patch or upgrade their install), since unpatched instances of FCKEditor could break functionality on websites far and wide for years to come, and since in some ways the distributed nature of the problem means there is less visibility than when a major website suddenly ceases to work correctly.
I think this also highlights the importance of web “library” or “component” authors doing things correctly from the beginning—not browser sniffing at all, but instead testing for features—because their code will be used widely and, as I understand it, they have little control over getting consumers to update when there are fixes for broken things like this.
If you’re going to write something for wider consumption, or that you think may one day be useful to large audiences, please take the time to get things right from the beginning, especially if your code doesn’t have a dead-simple upgrade experience. Your users, and their users, and even other unrelated software vendors, will thank you for it later.
(And remember: only you can prevent broken browser sniffing! 
)
Permalink
01.30.10
Posted in Software at 8:06 pm by Smokey
There’s been a little news recently about Adobe’s Shockwave Player plug-in (anyone out there still remember Director? The application people used to use to make multimedia demos for CDs, and for which Shockwave was invented as the companion web player?), though I imagine in most places this news been drowned out by the “news” that Adobe’s Flash Player plug-in still isn’t anywhere to be found on iPhone OS-type devices.
Specifically, the news about Shockwave Player (aka Shockwave for Director, back when Shockwave was the “it” brand and Shockwave Flash was the new kid on the block) has a security vulnerability and “users” need to remove any previous Shockwave 11 and update to version 11.5.6r606 to protect themselves. This would be all fine and dandy, if people who actually used Shockwave were the only ones to have it installed in the first place.
Coincidentally, however, Security Update 2010-001 was released on the very same day (19 January) as the Shockwave vulnerability and the new version 11.5.6r606. Guess what? On Mac OS X 10.5 and 10.6, Apple helpfully reinstalls…Shockwave 10, version 10.1.1.r16, from February 2006! Luckily Shockwave 10 is PPC-only, so it won’t even be loaded by browsers on most Macs running the new Security Update 2010-001, but it’s still another piece of useless cruft.
If you’ve installed Security Update 2010-001 (and if you haven’t, go start Software Update right now), you probably want to remove this ancient version by removing the support folder and the plug-in itself:
/Library/Application Support/Macromedia/Shockwave 10
/Library/Internet Plug-Ins/NP-PPC-Dir-Shockwave
For those of you with PPC Macs, I’m not sure whether version 10 or 11 wins out if you end up with both of them installed. However, if you do need to play Shockwave animations in Camino 2, you should be sure to remove version 10, as Camino 2 no longer contains the hack that Shockwave 10 required in order to be loaded by modern browsers. In any case, Shockwave 10 probably has security vulnerabilities, too, and you’re likely to be best off moving to version 11.5.6r606 and staying up-to-date.
Oh, and, Apple, could you please not plague us with any more Shockwaves from the distant past in future Mac OS X security updates? That would be swell.
Permalink
12.31.09
Posted in Camino, Life at 8:05 pm by Smokey
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!
Permalink
Posted in Camino, History at 12:24 am by Smokey
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!
Permalink
12.10.09
Posted in Software at 10:33 pm by Smokey
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?
Permalink
12.08.09
Posted in Camino at 1:40 am by Smokey
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.
Permalink
11.18.09
Posted in Camino at 7:05 pm by Smokey
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!
Permalink
« Previous entries Next Page » Next Page »
