Escaped Thoughts

Playing Nicely In Other People's Sandboxes

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.]

Other's Thoughts

From the weblog افكار و احلام - Tue, Mar 20, 2007
Troubleshoot Camino 1.1

Troubleshoot Camino 1.1 is out.
Troubleshoot Camino is a small AppleScript droplet I wrote, inspired by Stuart, to facilitate testing Camino under a fresh profile in troubleshooting situations. You can drop your copy of Camino 1.1a1 or higher on Troub... [more]

From the mind of Chris - Sat, Mar 24, 2007

Good luck with that 'hacks can be good citizens' thing. That idea was part of the (engineering) reason the Copland OS was such a mess (the management reasons were more mundane, but equally devastating).

From the mind of Stuart - Sat, Mar 24, 2007

We didn't come up with the idea that allowing hacks would be a good idea; we have no choice. This post was written because given the reality of the fact that people are writing hacks that inject arbitrary code into Camino (or just tamper with the bundle itself), I thought it might be useful to lay out some best practices that people could choose to follow if they want to help make things easier on both themselves and us.

From the mind of Jason Harris - Sun, Apr 01, 2007

I've added the above check to my ShapeShifter codebase. If the host application has bundle identifier "org.mozilla.camino" and the "CAMINO_DISABLE_HACKS" environment variable is present and has non-zero length, ShapeShifter will deactivate within the host application.