Several people have asked (as people have from time to time even in less uncertain times): Why don't we all just work on Firefox for the Mac instead? I understand why people think that makes sense. Camino is a browser in the Mozilla family, Firefox is a browser in the Mozilla family. Both run on the Mac. Basically the same thing, right?

What the question is missing is an understanding of the sorts of things that motivate people to contribute to open-source software in their free time. I don't know everyone's motivations for working on Camino, but of those I do, none picked it by deciding that they wanted to work on a Mozilla-family browser and then flipping a coin. Even if it were entirely a question of project goals, Camino and Firefox don't have the same goals, once you get beyond the “make a browser” part. But speaking for myself, the project goals are only a small part of why I'm here.

Off the top of my head, major reasons I work on Camino:

• I want to work on software I care about personally.
• I want to build Mac-focused software.
• I want to write Cocoa/Objective-C code.
• I like working with a small group where I know everyone, and interpersonal politics aren't an issue.
• I like having significant influence over the development of the project.
• I like being able to reach decisions quickly, without bureaucracy.

Firefox offers me exactly zero of those things. So the simple answer to the question of why I don't just go work on Firefox is that it wouldn't be rewarding for me. And since since we're talking about my free time, that's the only reason that matters. And while I don't speak for everyone else, I'd be surprised if my list doesn't overlap heavily with most of the other Camino developers.

(I could also list several reasons I would specifically not want to do it, personally, but those are probably not as generalizable to others.)

Category: Camino

Comments (2)

Today a major hurdle for the long-term future of Camino was announced on one of the Mozilla newsgroups. As our blog post suggests, there's a chance that Camino 2.1 will be our last release. It all depends on whether this new direction is something that will attract enough new developers for the work involved. And while our dwindling developer population has been sad on one hand, I think it is actually a side effect of something very positive: a huge improvement in the Mac browser landscape.

Pretty much everyone who worked on Camino (and before that, Chimera) did so because they wanted to build the browser they wanted to use, but couldn't find. We worked on Camino because it was the best browser out there (in our opinions), and we wanted to make it even better. And frankly, for a long time there wasn't much competition. Mac IE became more and more out of date until it faded into history. Safari started out anemic even by Camino's “keep it simple” standards, and didn't see a lot of change at first. Firefox felt like what it mostly was: a Windows app that happened to run on the Mac (and it was the only other open-source option). A small group of volunteers was, for a long time, able to keep up with—and even beat in many users' opinions—the other browsers.

But now we live in a very different world; one where there are good browsers pushing eachother to get even better, faster. Safari has closed the compatibilty gap and is focusing more on features. Mac Firefox (while still not my favorite) is now more of a Mac app built with a cross-platform toolkit than a Windows port. Chrome has come along and (in my totally unbiased opinion) made a compelling case as a browser that both offers power users power, while holding close to some of the same principles that are at Camino's core (and added another major open-source player to the field to boot).

On the web technology side, things are moving much faster these days too. We've fallen behind Firefox in shipping major Gecko revisions (not least because of the issues mentioned in our blog post); we're only now about to come to par with Firefox 3.6. Being a year behind wouldn't have been such a big deal for much of Camino's lifetime, but recently a year is a very long time in the web world. It's already reasonably common to see sites that don't support Firefox 3.0 (and thus Camino 2.0).

So while I am sad to see what could be the beginning of the end for the Camino project, I have to cheer at the underlying causes. And even if Camino does end with 2.1, there's no question that its legacy will live on. A number of Camino alumni are hard at work building those browsers that have changed the landscape. It's clear to me that without Josh Aas the Mac version of Firefox would not have seen the improvement that it has, and it's certainly no coincidence that Mike Pinkerton helped craft the browser that won my daily usage away from Camino. And let's not forget that Firefox started out as, essentially, the Windows version of what was to become Camino.

So whether or not there is a Camino 3, there's no doubt that Camino helped create the browser world that we live in now. I'm proud to have been a small part of that, and thankful to everyone who helped us along the way.

Category: Camino

Comments (0)

If you are a Camino user, and you've encountered WMV video or audio online in the past couple of years, you've probably seen pages inexplicably scramble themselves as you scroll, type, or select text (although you probably didn't realize that it was because of WMV content in another window or tab). This is due to an old bug in Telestream's Flip4Mac plugin which, since it's a third-party plugin, we rely on them to fix.

Six months ago, I had the opportunity to talk to a Telestream engineer about this issue. To make sure I could describe the problem as accurately as possible I spent about an hour testing pages with WMV content and looking at what exactly happened to other tabs and windows (that was the first time I'd personally looked into it, since I knew that others involved with Camino had talked to Telestream and been told that it was being investigated at their end). After that hour, without looking at any code or having any special knowledge beyond a basic understanding of how plugin drawing works on the Mac, it was clear how they were corrupting the graphics context: the plugin was changing the location of (0, 0) out from under us.

I had assumed that they already knew this, and that the problem was figuring out how to fix it, but as it turned out, the step from knowing that to finding and fixing the bug in the Flip4Mac plugin was tiny. So I found myself wondering: if it took me an hour to do essentially all of the work necessary to get this bug fixed, just by looking at the behavior, how much time could Telestream—with access not only to their code, but to the specific changes that they made in the version that first introduced this bug—have put into investigating in the year and a half since we had been assured that they would look into it?

If it were just that, I would write it off to a communication failure and think nothing more of it. Perhaps it was never made clear to them just how severe the problems this bug caused were, and certainly we should have followed up with them regularly to ensure that the bug didn't fall though the cracks by accident. The important thing was that now they had a fix in hand, and they understood the severity of the issue, so surely a fixed version would be available soon.

But here we are, six months and two releases of Flip4Mac later, without a fix. I was disappointed that the 2.2.0.49 release at the end of December didn't have the fix, but not too surprised; there's a whole release cycle to go through to get fixes out to users, and a month-long cycle isn't at all unreasonable—although it certainly suggested that they didn't take this issue as seriously as we do (if somehow Camino were making the entire system unusable for 2% of our users every time they launched it, and we had a fix, we'd risk slipping a release slightly to get it in, without hesitation). We followed up, just to reiterate that we viewed the fix as critical, and why: that it was not only damaging the WMV experience for hundreds of thousands of their users, but that it also crippled the entire browser for those affected, creating widespread problems for users, and offloading the large support burden of their bug onto us. We made it clear that this was by far our most frequently reported bug. We've made these points to them a number of times over the past six months.

Earlier this week, there was a new Flip4Mac release (variously labeled in the download as 2.2.0.49A, 2.2.0.49R, and, confusingly enough, just 2.2.0.49 again), the second since they have had a fix. It didn't include any release notes (the release notes they link to are the original 2.2.0.49 notes), so we don't know what they did fix, but it definitely didn't include the Camino issue.

A release process where an important fix takes more than six months to get into a release isn't plausible, so the only possible conclusion I can reach is that Telestream's management has made the explicit decision that fixing a problem that affects every single Camino user using their product isn't even moderately important: not important enough to slip into a release that was winding down, not important enough to get its own tiny bug-fix release in a span of five months, and not even important enough to put into a release that could not realistically have been assembled until well after they had this fix. So users continue to suffer, and we continue to shoulder the support burden and the negative publicity of their bug, because they apparently don't think that Camino matters.

Since Telestream is choosing not to fix the bug, I'm releasing a stop-gap fix: this tool will modify the released version of the Flip4Mac plugin to remove the problematic code, so that it will no longer corrupt drawing throughout Camino. I can't easily make any complex changes, so unlike a real fix to this bug it won't be selectively applied to Camino; as a result, WMV content may behave differently in Firefox once you run it (Safari uses a different plugin, so should not be affected in any way).

Hopefully, Telestream will reconsider the importance of this bug, and the workaround won't be necessary for long.

Category: Camino

Comments (4)

I've been looking around at reactions to the release of Camino 1.6, and a lot of it could be summarized as: “So?” The points are generally valid; amid the hype around the upcoming release of Firefox 3 (and to some extent, all the WebKit hype), releasing a new version using Gecko 1.8 (as seen in Camino 1.5 and Firefox 2) is hardly ground-breaking. But then, it wasn't meant to be, which is why it's Camino 1.6, rather than Camino 2—that would have been more clear if we'd released it last November as we had originally hoped, but such is the nature of trying to do scheduling in a volunteer project. Camino 1.6 is, as it was intended, just an incremental improvement; nice if you were already using Camino, but not nearly as exciting to read about as Firefox 3. (Here's a hint for the people wondering why we didn't use Gecko 1.9 by the way: Gecko 1.9 development is very, very closely tied to Firefox 3 development, and Firefox 3 isn't out of beta yet.)

If it were just the unfortunate timing of releasing amid flurries of stories about how Firefox 3 is just around the corner and will bring about world peace and cut through tin cans without getting dull, having press coverage like “Good news for those of you who are part of the ever-shrinking community that still uses Camino” (thanks for the love, Ars) would be easy to ignore, but I think the real issue is a more lasting one: the change in Safari's place in the web.

In the past year or so, WebKit has made very significant advances in compatibility, the iPhone has raised WebKit prominence, site authors are finally starting to get the idea that locking out the browser that comes installed on the machines of 5+% of their potential visitors (as well as the only one available to iPhone users) is probably not a good idea, and Safari is available for testing (and with Drosera, potentially development) on Windows. All that adds up to far fewer people finding themselves in need of a browser other than Safari to use all the sites they need to, which used to be a big part of why people turned to Camino.

That leaves us competing almost entirely on browser features and UI. But things have changed there too: with Safari 3, Apple changed their approach and actually back-ported a new version of Safari to the previous OS, rather than just back-porting WebKit as they had been doing. Assuming that continues, historical OS X adoption rates tell us that new versions of Safari will be available to almost all Mac users, rather than only about half, and so we lose another large uncontested (by Safari) user base. In a head to head match between Apple and a handful of very-part-time volunteers, it wouldn't take much effort on Apple's part to move fast enough that we wouldn't be able to keep ahead of them.

To be clear, I'm not complaining. Camino is about giving users a sleek Mac browser that Just Works; if Safari is equally good at being the browser that we have been working to build, then users win, because the browsing experience we wanted to provide is pre-installed on their machines. And it's not like we are in this for the money. I'm also not saying I'm ready to hang up my hat just yet (nor am I in any way, shape, or form speaking for the Camino project; this is all just my own musing and opinions); just that I spend a lot of time recently thinking about what might be next for Camino. Certainly, in the short term, we work to get Camino 2 out there soon, based on Gecko 1.9 and with a few new features that we've ween working on tossed in for good measure. Beyond that, the path is (to me, at least) unclear.

Category: Camino

Comments (9)

This is another post in my informal series of Camino public service announcements (yes, I know I promised to post about things other than Camino, but not today).

I see a lot of feedback from Camino users. I read basically every feedback email, Camino forum post, and bug report that comes it, and I answer a fair number of those. Mostly, people are fine, and I don't mind doing it. However, there is a class of feedback that comes from users who are apparently very misguided about the way things work, and there have been enough of them recently that I feel it's worth commenting on. I know I'm far from the first to talk about how not to interact with an open source product as a user, but everyone's take is a little different. I'm not foolish enough to claim to speak for the entire open source community (as in the case of the much-discussed HandBrake post, which makes the absurd claim that no open source software cares what its users want and that feature requests are therefore pointless). I won't even claim to speak for the Camino project; just myself, from the standpoint of one of the people dealing with all the feedback we get.

As I said, mostly people with bugs or requests are perfectly reasonable, and I'm glad to help. However, there are some people who come out of the gate rude, belligerent, and/or with an attitude of entitlement. They seem to be operating under the delusion that they can treat us however they like, and we have an obligation to be friendly and helpful anyway. Nope. If you send me email because you want me to help you, but you start it off by insulting me, I'm not likely to bother.

Since the common refrain is a variation on “do what I want right now or I'm never using Camino again”, I assume the belief is that we are desperate to keep every user. What these users don't seem to understand is that while this tactic may work in the commercial world (although I'd suggest that perhaps they'd have better results there if they started off at least being civil), there's a huge difference between what you can get away with while dealing with someone being paid by a company that wants to keep getting your money, and what someone is going to put up with when they are spending their free time helping you with a product they made in their free time, and give away. While in many cases I probably could be obsequious and calm these users down, convincing them that Camino is worthy of them... why would I? If they stick around after having learned that being obnoxious is a useful strategy, what have I gained for myself and the Camino project? More abuse down the road.

I'm thrilled that lots of people like Camino, and I'm always glad to turn reasonable users with problems into happy Camino users by helping them out when I can—but I couldn't care less how many abusive users storm off in a huff because I wouldn't fall all over myself to placate them. That's not to say I'm abusive to those people in return; stooping to their level is not only pointless, it reflects badly on the project. But anyone who tries to use the threat of changing to another browser as a club to force me to do something for them or as a shield for rudeness shouldn't be surprised when I happily tell them to enjoy whatever browser they choose instead.

Category: Camino

Comments (5)

We released Camino 1.5 today, at long last. Lots of good stuff that we are really excited to get out there to wider audience of users. I won't go into all the new stuff, since the site does a great job of covering all that. Instead, I want to preemptively respond to some of the feedback that we routinely get around release time:

“Big deal, <some other browser> already has those features.”
Yes, but <some other browser> has a paid, full-time development staff. If the worst that can be said about us is that we, a very small group of people doing volunteer work in our free time, can stay largely competitive with browsers that people are paid to work on, I'd say we are doing pretty darn good. That's not to say we don't ever want to innovate, but we have to be roughly on par with everyone in terms of core features for any innovations to matter.

“It crashes on every launch/never renders any pages/other catastrophic failure on every basic task. Nobody download it!”
Um... did it occur to you that if it didn't work at all, someone would probably have noticed before we released it? If you want to use input managers to hack your apps, that's fine, but it's irresponsible to use them without understanding that when you hack something, it may not, you know, actually work anymore if it's done wrong, and that that's not our fault. Remove your input managers (in this case, 1Passwd and CaminoSession, both of which will cause total meltdown if you aren't using their latest versions) before flaming us or telling everyone you can find that our product doesn't work.

“Who cares, it still doesn't do <X>. What have they been doing all this time?”
See above under “small group” and “free time”. If your complaint is that we don't spend enough of our free time making you happy... well, as our fearless leader likes to say: “Bite me”.

Of course, most people don't treat us like dirt; I just have to vent around release time as a coping strategy. To everyone who gives us positive feedback: thank you! To everyone who gives us constructive feedback, thank you as well, and we certainly listen—and be sure to check out 1.5, as it may have that feature you've been asking for!

Category: Camino

Comments (1)

I've made a small foray into the world of Camino add-ons myself. Somewhat ironic, perhaps, but at least I did follow my own advice.

It started with ChimericalConsole, which is a simple JavaScript console for Camino. We've always said it would be something that would be best done as a third-party tool, since we aren't developer-targeted, and since no-one had done it yet and I found myself using the ugly Console logging hidden pref one too many times, I went ahead and wrote it as an add-on. I'm still not really happy about using an input manager, but hopefully this will motivate me to work on a real plugin architecture.

Then, mostly just to show the vocal minority that wants it that it could in fact be done outside of Camino itself, I wrote AsceticBar, which removes the favicons from the bookmark bar and adds Safari-like markers to folders and tab groups. I still think it's a much worse UI, but hopefully it will mean one less group of people agitating for the aesthetic prefs we have always said we won't be adding to Camino.

Both are available at my new hacks page. Enjoy!

Category: Camino

Comments (0)

Although I said we are entirely focused on getting 1.1 out the door, we have been giving some thought to what comes next. One big goal is to start iterating faster; there's a balance between releasing often enough to keep people interested and getting new features in their hands and not releasing so often that people stop bothering to update because each new version brings only one or two small things that they don't care about.

Since it's hard to know what the development team will look like in the future we can't plan too much yet, but we have started looking how to make 1.2 happen soon by targeting a few feature areas and focusing pretty closely on those. That's not to say we won't keep fixing miscellaneous bugs; just that we'll be mindful of not tackling anything too big that isn't something we really need for 1.2

Once 1.2 is out, we can turn our attention to 2.0. That may seem like a strange version number jump, but 2.0 is when we plan to move to Gecko 1.9, which will be quite a change. The biggest is the switch to Cairo, an entirely new drawing system that should solve some long-standing performance issues in Camino. Perhaps more visible to many people is the awesome work that Josh has been doing to rewrite the form widgets that Camino uses and Firefox will start sharing with us; it's still in progress, but already it fixes many of our old widget problems, gives us a much cleaner code base to work from, and (probably most controversial to some Camino users) will give us the fall-back behavior that lets simple widgets look aqua, but styled widgets look like the page author intended.

What about Camino-specific changes in 2.0? Definitely too early to say. Have some ideas, and know a thing or two about Cocoa? Stop by #camino on irc.mozilla.org and we'll be glad to start assigning you features :)

Category: Camino

Comments (0)

“So 1.1 beta is pretty cool,” we hope you are saying to yourself, “but when is 1.1 going to be released?” Hopefully the answer is very soon, but as always the real answer is, “When it's ready.” We really want to get 1.1 in everyone's hands, but we need to make sure it's solid. Right now we have at least one random crasher that we are hunting down, the sporadic “some pages don't render until the window is resized” bug, and a few smaller regressions. What we really don't want is to ship 1.1 and have people saying “1.0 was much more stable; I guess I'll stick with that.”

So we've basically locked down our features, and are limiting most bugfix work to things that are regressions from 1.1. The last thing we want to do at this point is risk adding more bugs while we squash the last of the bugs we know we have in 1.1 beta. So while we are definitely filing away all the feature requests we are getting in response to the renewed interest sparked by the release of the beta, whatever awesome new feature you suggested, no matter how much we would like to implement it, is not going to be in 1.1 if it's not 1.1 beta. Right now our all-consuming priority is to get 1.1 out to everyone who has been patiently for all the cool new features we've already added since 1.0. On the other hand, we do want to hear about each and every “this works in 1.0.x but not in 1.1” problem you see, so we don't accidentally leave you wanting to stay with 1.0.

Category: Camino

Comments (0)

I've been reading a fair number of the little mini-reviews people have been posting, and the comments in response to them. In no particular order, some thoughts about various things I've seen:

• Session saving seems to be pretty popular with everyone, so I'm glad we got that for 1.1.
• People still think the Acid 2 test matters. I guess I was hoping it had died down and people had forgotten, but no such luck. The most disturbing was a comment someone made that “Safari is a more standards-compliant browser because it passes the Acid 2 test and Camino doesn't” Um... not so much. WebKit is getting better and better at compatibility, but when it comes to actually working with the most sites, WebKit most definitely does not beat Gecko. Large portions of the Acid 2 test are about obscure edge cases that may never appear on any site. The fact that jinglepants did a serious of very target fixes to make WebKit pass Acid 2 was cool, and apparently a huge publicity win, but it did not magically solve all of WebKit's other compatibility bugs. It's like all the hubbub that comes up periodically in the video-card world: it's nice that they can micro-optimize their cards to look good in the benchmarks that everyone uses, but what actually matters is whether or not the hot new games will actually run.
• Yes, we are not on the leading edge of browser features. There were a fair number of “Yawn, Browser X had that feature a year ago”. comments. You know what Browser X has for every value of X I saw in those comments? Paid, full-time developers. The fact that we are staying at least somewhat competetive despite having less that one full-time developer if you add all of us up and all of us being volunteer is, I think, pretty cool.
• Either most people didn't read all the release notes, or they all work for the government. The notes were organized by release, top down, so “New in 1.1b“, then ”New in 1.1a2”, etc. Many, many mini-reviews mentioned Kerberos support as one of the big new features they picked out of those lists—a feature that I think we only ever had requested twice (both by people with .gov email addresses), but was new in 1.1b. So unless there was massive hidden demand for it, its prominence in other people's versions of the feature list suggests a lot of people just never read past the first section.
• We don't have anti-phishing support. This is the one that bothers me, because we never said it, and it's not true. This appears to be people blowing the MySpace password-stealing fix out of proportion; if I have a page on a site you log in to, and I can steal your password without your knowledge, that's not phishing, and that's what we fixed. We'd like to have real anti-phishing as a feature, but we don't yet, and it's unfortunate that people will likely judge us as not having lived up to claims that we didn't actually make.

Of course, that's all smaller, random stuff. The overwhelming tone I saw is that people are happy with the way 1.1 is shaping up. Once we squash a few important bugs, we'll be ready to ship a 1.1 that a lot of people are really going to like.

Category: Camino

Comments (0)

With the fairly wide-spread announcement of 1.1 beta, there have been a whole lot more people trying out development builds than the usual nightly build users. With them is coming a flood of emails, forum and software tracker posts, and feedback emails with variations of “I downloaded 1.1 beta and it doesn't work at all”. The problem usually takes one of two forms: CamiTools, or an older version of CaminoSession. But of course, most users just blame us.

This is partially our fault, because there's no extension API in Camino. We'd like there to be one, but frankly we just don't have the time and manpower right now, as getting the browser itself right is higher priority at the moment. So, naturally the people who really want to make extensions are finding other ways. But it's also a significant amount not our fault, because we don't control other people or their code. So if you are one of those people who really wants to write a hack for Camino, here are some guidelines that, if followed, will make us much, much happier. The less time we spend trying to support users having problems with code we didn't write, the more time we have to code. Who knows, maybe we'll even find the time to write an extension system.

1. Don't. Ask yourself: do you really have to write it as an add-on? Camino is open source, and we like contributions. If a feature you want is missing, there's a reasonable chance that we'd like to see it too, and just haven't had the time. CaminoSession is an example of something that I wish had never been developed as an add-on, because we had an open bug for it, and it could have just been built right in. Yes, there are plenty of things we have said we aren't ever going to do in Camino, so this isn't always an option, but please consider it first.

2. Assume nothing. Far and away the biggest headache that CamiTools brought on was the option to use the Metal style for Camino. It worked (during the times that it did work) by shipping a copy of our main nib file with the Metal flag turned on. The assumption here is that we would never change our nib. Meaning, nothing about the UI in the browser window would ever change. If CamiTools had checksummed the original files and only replaced them if the checksum matched, then it wouldn't have been a big deal, since it would have just not been able to enable Metal until a new version was released. Instead it blindly replaced, and if we had changed the nib since the last CamiTools release then Camino just wouldn't open any new windows. Not so fun.

   This applies to input manager hacks as well. CaminoSession called a lot of methods in Camino code with the assumption that they won't change. Several times we changed methods that CaminoSession happened to use, and because it interposes critical methods, when it fails it brings all of Camino down with it. Our number one support request for Camino 1.1 beta has been people who just see blank pages that say “Loading...” because they have an old version of CaminoSession. People forget they installed it, or think they uninstalled it when they haven't, or it just never occurs to them that it's CaminoSession. Camino 1.0.3 works, Camino 1.1 beta doesn't, therefore 1.1 beta is buggy and broken. If you are calling Camino methods, check for all of them when loading, and if any of them are missing, either silently disable or tell the user “Hey, you need a new version”, and either way it'll just be your add-on that stops working, instead of Camino itself.

3. Call a spade a spade. Maybe I'm just old-fashioned, but I really don't like to see hacks being called plug-ins. To me, plug-in implies a supported method of extending an application's functionality. Hacks are not supported. More importantly though, just make it really clear that it's not supported somewhere that users may actually read it. I had at least one user actually arguing with me in a bug that because a nightly build broke CaminoSession it was a bug in Camino, even after I tried to explain. After that, Ben (the author of CaminoSession) helpfully added a prominent note to his download pages, and that did make a noticeable difference (of course not everyone will read disclaimers, no matter how prominent, but that's just the way of the world).

4. [Edit 3/20]: Honor CAMINO_DISABLE_HACKS. Troubleshoot Camino is a helpful tool that we can point people to for debuging that lets them run with a fresh profile. Unfortuntely, input managers and other such forms of hackery don't live in the profile folder, so they can cause problems even with a fresh profile. To make it easier to isolate problems when they happen, please respect the CAMINO_DISABLE_HACKS environment variable; if it's set (which we can easily do from Troubleshoot Camino), just don't load:
   

       const char* disableHackValue = getenv("CAMINO_DISABLE_HACKS");
       if (disableHackValue && strlen(disableHackValue)) {
           // Troubleshooting mode is on; don't do any swizzling
       }

Number 2 is really the key take-away. If you are willing to ride the choppy waters of keeping something working in constantly changing nightly builds, great—just be careful not to sign us up for the added workload too.

Note: To be clear, I'm not trying to hate on CaminoSession in particular, it's just that it's where we learned these lessons the hard way. I think both we and and Ben were broadsided by the problems, as it was new to all of us, and things got significantly better as we started talking more. And I guess that's point 5: come to #camino and chat with us, or email the mailing list. Communication makes all the difference.

[Edited 3/28; I wasn't aware that “haxie” is an Unsanity trademark.]

Category: Camino

Comments (4)

Another long dearth of posts, as I've been really busy lately. In very related news, Camino 1.1 beta is out, so get it while it's hot!

In honor of the beta, this installment of my post-silence post-a-day-for-a-week will be Camino-themed. I'll have more to say about the beta itself later this week, but today I want to announce my beta-day present: CookieThief. It's not much of a present, I grant you, but I made it myself, and it's the thought that counts. After I got Safari Keychain integration working and was talking about how I hoped it would help Safari users try out Camino, Smokey pointed out that it would also be nice if there were a way for Safari users to bring their cookies over too, and thus was born CookieThief. Since it turned out to be almost no additional work to make it go the other way too, it's a full Camino <–> Safari cookie sync tool.

Sure, it lacks a disk image, a ReadMe that no-one will ever read, fancy artwork, and other such amenities, but it does its job, and hopefully it'll be one less barrier to trying out Camino. Eventually I'd like to work an initial cookie import into Camino if we can get the UI right, but even then CookieThief might be useful for those who bounce back and forth between the two browsers.

It's not very widely tested, so I apologize in advance if it sets your dog on fire. If it does, I'd definitely like to know about it so I can fix it.

Unless you have one of those annoying little yippy dogs, that is.

Category: Camino

Comments (2)

Safari keychain interoperability landed today, so there's now one less reason for Safari users to resist trying out Camino when 1.1 is released. Yay! It should also be a big help to people who keep both around to deal with sites that are problematic in one or the other; not everyone is going to use Camino full-time, and hopefully this will make it a little more useful for those people to keep around.

There's certainly work left to do in keychain—storing multiple accounts for a site is still something we need to support—but this was a big step forward and I'm excited to see it land. I'm looking forward to seeing how well it works for people in the coming weeks; I know there are likely to be some corners I missed, but I'm hopeful that they will mostly be small ones.

Category: Camino

Comments (0)

Today was cascading build failure day. Whee! Fun for the whole family. It's going to be a while before I start feeling bad about at any times I might briefly break the Camino tree again; today I spent enough time on build failures that were not my fault that I think I have a large stockpile of build karma.

The fun began with an SVG change that assumed Cairo, which therefore started the Camino tree burning. So SVG was disabled in Camino, but then Xcode was unhappy about a missing file. I misunderstood the reason for the missing file and thought the best way to deal with the problem was to go ahead and land my Cairo build patch right away. Which did need to happen soon, but in retrospect it would probably have been nice to wait for another day just to spread out the flames a bit. So anyway, when the tree stayed red I learned that the file was missing even with SVG enabled, on purpose, so turning on Cairo didn't actually help that particular problem. So I ripped out references to that file, and would have gone back to doing something useful with my day except that right around then we discovered that Cairo didn't build on 10.3. Oops. And the red continues.

What followed was a tedious debugging process where we finally found that this was a latent bug in cairo-cocoa, that no amount of testing on 10.4 would have found (yay! not my fault!). One of the files was being built in a very un-kosher way that hid (on the Firefox build machine) the fact that it was written using 10.4-only stuff, when it's supposed to build for 10.3. And our build machines are 10.3. And there was no easy fix. Good times.

So faced with either backing out Cairo (which would just open us up for more pain due to the trunk==Cairo mindset of the moment) or hacking around it in fairly ugly ways, I chose the latter. All was going well, until I discovered that one of our build machines is 10.4, and because of how badly messed up the compiling of that file was handled, My hack had broken the ability to build for 10.3 on 10.4. So the hacking got uglier, to the point where I thought long and hard about just backing out Cairo instead. But there the new hacks are, and over nine hours after this roller-coaster of build excitement began, things are finally green again.

Thanks for asking—how was your day?

Category: Camino

Comments (1)

The list of bugs for 1.1 is definitely shrinking, and I just landed both the first part of session saving (woohoo, easy nightly-build upgrading!) and a fix for a big popup-blocking regression. Keychain is also getting very close to landing, so I'm hoping that in the next week or two I can get some cool new feature work done on both that and the session saver.

It feels very good to be splitting time between feature work and polish, since it means I feel like we're neither rushing features out without smoothing edges, nor delivering an update that won't have some substantial new user features. Should be a solid release.

Category: Camino

Comments (0)

My lesson for the day: the time before you can actually go to sleep is substantially longer than the amount of time it takes to discover that you accidentally broke the build and back out the offending patch. I'm definitely not doing checkins less than two or three hours before I plan to go to bed in the future.

Category: Camino

Comments (0)

Most of the time I haven't been working recently has been spent on Camino, which is part of the reason it's been so quiet around here. For a while I was averaging about a bug fix per day, which was pretty satisfying. I'm scaling back a bit now, partially because I need to spend time on things besides Camino at least occasionally, partially to make sure I don't burn out, and partially because I've overloaded the review queue lately and don't want to make it too much worse until it's had time to drain.

Most of the work I've been doing has been to try to chip away at the 1.1 bugs, many of which have been minor polish that Camino has been needing for a while but weren't ever really high enough priority to fix. Having them on the 1.1 list was good incentive to just burn through them instead seeing many of them punted (again, in many cases).

There are some bigger ticket items on my plate too though; on top of the Keychain rewrite I did to celebrate my return, I'm hoping that there will be time in the 1.1 schedule to do the part users will actually care about: Keychain interoperability with Safari. We've heard lots of times that people trying Camino after using Safari are dismayed to discover that they have to try to remember all their site passwords... which mostly they don't because they've just been letting Keychain do it for them, that being the entire point of the Keychain. I think a lot more people will be willing to give Camino a try once we pick up Safari-stored passwords, and it should also be a boon for those who can't quite decide and go back and forth regularly.

The other larger thing I'm working on is session saving, which is something I've wanted for a while. I tend to accumulate lots of open pages over time as a sort of holding area for my brain. This works fine up until a) I want to either install an OS update or upgrade Camino, or b) Camino crashes (pretty rarely, but it does happen since I live on development builds). When I find myself delaying system upgrades for upward of a week just because I don't want to go to the trouble of manually saving all my browser/brain state, there's definitely a need for the software to be doing something different—and of course minimizing data loss is always a good thing. I'm a little concerned that users won't understand why things like forms and AJAX-y pages don't look just like when they quit; I suspect there will be some unhappiness the first time people discover that it's remembering where they were, not the actual page as it was when they were looking at it. There's some hope that we may be able to leverage the work Firefox did for session saving and get the whole experience, but if not, well, losing a bit of data is better than losing lots, and there are still a lot of pages out there that do actually look the same when you reload them.

In short, I'm definitely feeling good about developing again, and definitely feeling good about the upcoming 1.1 release.

Oh, and I also did my first (mini) super-reviews and my first check-in recently, so that was pretty cool.

Category: Camino

Comments (1)

I celebrated my return to Camino today with 6 patches. Granted only one was at all sizeable, but it was still fun.

It's good to be back.

Category: Camino

Comments (0)

Congratulations to Josh! A great day for Camino (and Firefox), but a sad one for any other fine company that might have wanted to hire him. I expect that Camino will rock even more now.

(I also expect some tasty vegan dinners in my future ;) )

Category: Camino

Comments (0)

As my change over to the new job and new home gets closer, I'm finding myself in a state of limbo—my standing with the Camino project more so than anything else. Although I haven't actually started work yet, I have signed the requisite IP agreement. In absence of other information, I'm assuming that it took effect when I signed it, not when I walk in the door for the first time.

Now, this certainly isn't the end of the story, as I fully intend to begin the paperwork to see what my future is as soon after getting there as possible (without being a colossal pain to my superiors, that is). So in a few weeks I'll start the process of seeing what's what. Until then though, I'm playing it safe. Unfortunately, I don't actually know how safe to play it, so I'm leaning toward really safe. That means:

• No code contributions
• No bug triaging
• No substantive contributions to #camino on IRC
• No forum posts

The last at least is probably overly careful, but it's easier and safer to just take a clean step back for a while.

It's hard though, because I like troubleshooting in the forums, and (as sick as it sounds) I like bug triaging. And it's hard because I feel disloyal to the Camino team. It's not like we are swimming in developers, and it's looking like there will be almost no-one for the next month. The Camino team is awesome, and I hate to abandon them even for a short time—they took me in, answered my dumb questions, helped me get going doing real work, put trust in me, and generally made me feel like a real part of the team almost immediately. They're all very understanding of my hiatus, but in a way, that almost makes it worse. Since I don't think it's an exaggeration to say that I wouldn't have my new job without my Camino experience (both resumé and real-world Objective-C), and since it's because of that job that I'm taking a hiatus (hopefully nothing more), I can't help feeling like I'm giving them the short end of the stick here.

With luck, I'll be back soon. I'm sure given enough persistence I can find some way, even if it's curtailed or slightly indirect (e.g., working on some of the Moz Mac-only bugs, rather than Camino specifically), of helping out. And if I'm really lucky, the higher-ups will agree with my view: Camino isn't about competing with Safari, it's just about having more choice, and filling a slightly different niche. It's about enriching the platform.

Stay tuned.

Category: Camino

Comments (2)

Camino 0.8 came out somewhere around my layover in Denver last week, so I've been behind on the celebration. I've been catching up on the user reactions, and it's been quite heartening; besides the (surprisingly little) requisite bitching about how it's worthless because of one missing feature or another, the comments are very positive. The consensus seems to be:

1. It's much better than 0.7
2. It's quite solid
3. It's either almost as good as Safari, or better than Safari.

The fact that many people consider it to be on par with something 8 people work on full time, despite the fact that all the Camino-specific stuff is being developed by a handful of of people in their spare time, is very nice.

The best part, though, is simply the feeling of progress. Camino is not dead, and it is improving. We still have a ways to go, but we are going there! Unfortunately my contributions to 0.8 were fairly small, as I joined late in the game, so most of my pride isn't warranted. Here's hoping I can help see Camino through to 0.9 and beyond, in order to really make a difference.

Pink already thanked all the contributors, but being a modest guy he didn't thank the person who deserves the lion's share of the praise and thanks: himself. He's seen the project through lean times, a new Goliath challenger, several names, and continuous abuse by smart-alec contributors like myself. And he keeps it all going. Seeing just how much is involved, especially beyond "just" coding new stuff and bug fixes, I have a whole new level of respect for the job he does. Pink: you rock.

Oh, and I can't forget a big shout out to the donkey. As botbot will tell you, he's a vital member of the Camino team.

Category: Camino

Comments (0)

The final candidate for Camino 0.8 should be released today, bringing us very close to the 0.8 release that's been eagerly awaited for so long. We've all buckled down recently and cranked out some good stuff—it's nice that we can have a release in a time-frame that we were shooting for without giving up being a bug-fix-driven release.

Category: Camino

Comments (0)

Pink asked me to take a look at a bug causing Camino to open very slowly for people with a lot of bookmarks (read: way too many) to see if I could find any low-hanging fruit. Some profiling pointed at most of the time being spent posting system notifications to other components of Camino, telling them that a bookmark had changed and to update appropriately.

Only, those other components don't exist while bookmarks are initially loading. They haven't been set up yet. The upshot being that the bookmark-reading part of launching Camino will be about 6-7x faster once my patch lands. It doesn't hang much lower than that.

Note: the only people likely to notice this are those insane enough to have bookmark files that are, like the one I was testing with, 3+ Mb. (For reference, mine, which I consider reasonably-sized, is 100 Kb.)

Category: Camino

Comments (0)

Camino 0.8b is out, which should help put down the greatly exaggerated rumors of the Camino project's death.

The release was picked up by several mac sites. So now the feedback is starting to roll in on each of these sites, which is a mixed blessing. Yes, we want feedback. And people are using it and trying it out, which is great. But the problem is that most people online are 1) stupid 2) rude or 3) both. I'm not saying I want all the feedback to be positive, but a basic level of respect for others wouldn't hurt.

Good: Feature X would be very useful, and I really hope it can be included in one of the upcoming releases.

Bad: WTF is wrong with you?!! A brain-damaged monkey wouldn't make a browser without feature X!!! Every idiot knows that! I've been saying Camino needs it for weeks, and no one has done anything about it! What are you slackers doing?!?! Oh, and it's the slowest and ugliest POS browser I've seen in my life! If you weren't all so st00pid, maybe you could make a something that doesn't _SUCK_!!!!!

I exaggerate (slightly), of course, but plenty of comments and feedback have elements of the latter. Even if we weren't volunteers doing this in our spare time, that would still be very uncool. Given that we are, it's just totally beyond the pale. Yes, I mostly ignore those sorts of comments. But I like to dream of a world where I don't have to start every day with the assumption that many people I interact with are going to to be stupid, rude, and aggravating, and adjust my attitudes accordingly.

So for anyone wondering why I'm an arrogant elitist who thinks he's better than most people, all I can say is: spend some time on the internet.

Category: Camino

Comments (0)

That's right, I'm famous now, so you can all give interviews and say, "Yeah, I knew Stuart back before he was a famous software developer".

Ironically, I didn't find that bug to be "the most visible rendering glitch on Panther"—in fact, I pretty much only saw it in the test cases (apparently I don't visit cool enough sites). I would much rather have fixed a completely different bug, which drives me crazy on a more or less continuous basis (yes, I'm enough of a loser to still be on dial-up). I had hoped that underlying cause was the same, and I could fix both bugs at once, but alas no. It continues to taunt me by rearranging pages in modern-art-style ways as I scroll. Maybe it's a feature? "Camino: the only browser hip enough create modern art on the fly" We are looking for ways to set Camino apart from other browsers, after all. Who wants a boring old browser that does nothing more than spit out what it's given anyway?

Category: Camino

Comments (3)

I've installed 10.1.5 on my long-disused beta OS upgrade partition (I knew it would come in handy again someday!) so that I can try to help make Camino 0.8 rock-solid (or at least firm-dirt-solid) for 10.1.5 users before we leave them behind. This gives me the dubious distinction of being (so far as I know) the only Camino developer with 10.1, and thus the equally dubious privilege of owning all the 10.1-specific bugs. So, if you have any 10.1.5 Camino bugs, let's hear them!

Oh, and for anyone with 10.3 asking themselves, "Hey, wouldn't it be fun to switch back to 10.1?" the answer is: No. No it wouldn't.

Category: Camino

Comments (0)