07.30.08

Memo from 2006: CamiTools incompatible with Camino

Posted in Camino at 3:04 pm by

Back around the mid-point of this decade, CamiTools was a popular, if poorly-designed and dangerous, third-party preference pane for Camino. In particular, CamiTools exposed a number of hidden preferences that caused Camino or parts of Gecko to stop working properly, and its user-agent spoofing was implemented in such a way that the spoofed user-agent—often some version of Internet Explorer, which caused websites to send incompatible code to Camino—persisted for years without the user realizing it. The “preference tweaks” caused Camino to stop working correctly in bizarre and difficult-to-discover ways, and CamiTools caused the Camino triage and QA teams no end of headaches. Nevertheless, CamiTools was the first widely popular third-party preference pane, and it was even one of the three featured add-ons that “you shouldn’t be without” at PimpMyCamino, if I remember correctly.

I’m not sure at what point CamiTools first became incompatible with Camino; the last reference to it I can find states “Camino 1.0.x only,” which means it hadn’t been compatible with nightly builds since early 2006, hadn’t been compatible with milestone (alpha/beta) builds since late 2006, and with official releases since mid-2007. Jump forward another year-and-change from that and one would hope that CamiTools, which hasn’t been updated in three years and hasn’t been publicly available in nearly two, would no longer be causing Camino users and developers problems. Alas, one would be sadly mistaken. In the last few months I’ve seen one ancient user-agent set by CamiTools, we still encounter users in Bugzilla with it installed, and last night while checking Talkback topcrash reports, I found almost 20% of the incidents I examined (which made up about a quarter of the total incidents for this one stack signature) were a “crash on launch” or “crash when opening preferences” caused by CamiTools. I shudder to think of how many more there might be. If that weren’t bad enough, CamiTools had a sister program, CamiScript (also discontinued and presumed incompatible with anything newer than Camino 1.0.x), that also caused a rash of crashes on launch with Camino 1.6.1.

It seems like just about every Camino release we discover—the hard and painful way, via angry users complaining about us in forums and on software update sites—some new Camino crash caused by an old or incompatible third-party add-on trying to initialize itself inside of Camino’s process. These are the worst kind of crashes; users believe that programs which crash at startup are pretty badly broken, and they shout that experience out to the world while rarely contacting or working with the developers to discover the true source of the crash. In Camino’s case, these crashes (or public reports of them) not only dissuade new users from trying the program, but the crashes/reports also cause users to stick with the last version of Camino that “worked properly” (i.e., the last version of Camino that an incompatible third-party tool did not reliably crash), causing users to miss vital bug-fixes and critical Gecko security fixes that we release in updates and in new major versions. It’s frustrating as a development team to be fighting problems caused by code that is completely out of our control but which nevertheless crashes our application.

Please, if you still have CamiTools, any of its predecessors, or CamiScript installed, remove them at once. They really are incompatible with any recent version of Camino, and if they haven’t yet caused you problems, they will soon.

Second, if you crash when Camino is launching, check for any third-party add-ons and remove them. You can try launching Camino using Troubleshoot Camino, which will disable many recent third-party add-ons (though many older add-ons which are known sources of crashes or incompatibility cannot be disabled using Troubleshoot Camino), but searching for, and removing, all traces of third-party add-ons may be necessary, depending on the add-ons you might have installed.

Third, if you’re experiencing any sort of persistent problem with Camino, please visit the Camino forum provided by our friends at MozillaZine, or file a bug, and work with us. We can’t diagnose problems we don’t know about, or don’t have information about, so we can’t help make it stop (no matter whose code might be at fault).

Finally, let me repeat myself once again: CamiTools and CamiScript are incompatible with all recent versions of Camino. If you still have them installed, please remove them immediately. If you don’t think you have them installed, please check carefully and make sure they are not installed. (While you’re looking, please make sure any other Camino add-ons you have installed are up-to-date and not discontinued.) You’ll save yourself, and the Camino team, a lot of time and hassle, either now or sometime in the future.

8 Comments »

  1. User Grav­atarKurt said,

    07.30.08 at 3:30 pm

    Why not just blocklist the extensions? I’m not sure if Camino also uses this code from Firefox or not…if the later, disregard then.

  2. User Grav­atarSmokey said,

    07.30.08 at 4:35 pm

    Kurt: No, Camino doesn’t use the blocklisting code (in theory we could hook up the part that works on NPAPI plug-ins), but these are also completely different kinds of “add-on” code. Some of them (like CamiScript) are even written as InputManagers, which Cocoa automatically loads into every application process and therefore are impossible to prevent from loading (which is one of the main reasons Apple is deprecating InputManagers).

  3. User Grav­atarSmokey said,

    08.08.08 at 2:23 pm

    For more information about InputManagers and why applications have no control over them, see this article from MacJournals. (Hat tip to Stuart; I’d missed this before.)

  4. User Grav­atargeomom said,

    08.09.08 at 10:33 am

    Stoopid Question!
    How do I remove CamiTools? I’ve had it installed since before the dawn of time and have no idea how to remove it :-)
    Thanks!

  5. User Grav­atarSmokey said,

    08.09.08 at 11:29 pm

    geomom, CamiTools itself is pretty easy to remove: inside the Camino profile folder (~/Library/Application Support/Camino, where ~ represents your user folder) is a PreferencePanes folder. Inside of that folder should be a CamiTools.prefPane file, which you can simply move to the Trash. (If CamiTools isn’t in that folder but is still showing up as installed in Camino, look in the same place but start from the Library folder at the top level of your hard disk rather than from the one in your user folder.)

    Unfortunately, it’s much more difficult to get rid of any of the changes CamiTools might have made that could be causing other problems. The easiest way to do so is to quit Camino, completely throw away your current Camino preferences files (prefs.js and user.js in your ~/Library/Application Support/Camino folder) and the chrome.rdf file in the chrome folder inside your Camino profile folder, and then re-set all of your preferences when you launch Camino again. (Your bookmarks, history, cookies, and passwords won’t be touched by this.) It’s not pretty, but it’s the easiest way to be sure to root out all the remnants of CamiTools. :-(

    If you have any questions about the process, please feel free to stop by the Camino support forum.

  6. User Grav­atargeomom said,

    08.10.08 at 12:28 am

    Got it! Thanks!

  7. User Grav­atarSmokey said,

    12.17.08 at 3:14 pm

    In addition to the locations mentioned in my previous comment, you may also need to remove a flashblock.jar file from your ~/Library/Application Support/Camino/chrome folder.

    That file contains CamiTools/CamiFlash’s copy of Flashblock, which is horribly outdated and which will not function correctly in Camino 1.6.6 or Camino 2.0b1pre nightly builds since November 2008.

  8. User Grav­atarSmokey said,

    12.20.08 at 7:09 pm

    …and flashblock.css from your ~/Library/Application Support/Camino/chrome folder, too.

Atom feed for comments on this post · TrackBack URL

Leave a Comment