03.21.07
Posted in Camino at 12:27 am by Smokey
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 Troubleshoot Camino and Camino will run using all of its default settings, helping to find (or rule out) problems caused by changes you have made to Camino’s preferences or cookies. When you’re done checking for the bug or issue you were experiencing, quit Camino, and the next time you launch Camino, all of your old settings, cookies, bookmarks, and history will be restored. (In fact, your settings never moved; Camino just didn’t look at them. In the past, we had problems where some people would accidentally break or discard their profiles while trying to create a fresh profile. Thanks to Håkan’s work on CAMINO_PROFILE_DIR, we can now avoid this problem and automate the fresh profile-creation process.)
Unfortunately, in recent months a number of Camino add-ons have appeared that live outside the profile directory and are not disabled by a fresh profile. Sometimes these add-ons have caused problems, and they were hard for users to detect. The sole purpose of Troubleshoot Camino 1.1 is to provide a mechanism that, with the help of add-on authors, will ease troubleshooting by enabling a true “fresh profile” even when these add-ons are installed on a user’s Mac.
Technical mumbo-jumbo
Troubleshoot Camino now exports a CAMINO_DISABLE_HACKS environment variable. If you’re an add-on author, please have your add-on check for the presence of this environment variable when loading and have the add-on disable itself if the variable is set. Stuart has helpfully provided some sample code to check for this variable.
We on the Camino team recognize that Camino users will want features that we will never add to Camino (or we cannot, for one reason or another, add right now) and that third-party add-ons will appear to satisfy these users’ desires. By working together, we can ensure that a user’s experience is as painless as possible when problems do appear and that it will be easy to isolate the source of problems. If you are an author of a Camino add-on, we appreciate your cooperation in adding support to check for CAMINO_DISABLE_HACKS in your code.
Edit 2007-03-28: Don’t stomp Unsanity’s trademark in the variable name—although if there are any APE modules written specifically for Camino, I hope they will check for the environment variable, too.
Permalink
03.09.07
Posted in Camino at 5:15 pm by Smokey
Last weekend I noted we discovered that we had shipped Camino 1.1 Beta with a pretty serious random crasher. Thanks to some great detective work from Steven Michaud (author of the Java Embedding Plugin that ships in all Mozilla browsers) and some tooltip-wrangling by Stuart, we believe these crashes have been squashed. Talkback reports for nightly builds since the fix was checked in show crashes that may correspond to the one we fixed (Talkback lumps a number of things together, unfortunately) to have all but ceased.
Unfortunately, the branch nightly builds aren’t getting a lot of user testing right now. The lack of testing before 1.1 Beta was partly responsible for us shipping Beta with this crash, as we couldn’t tell until after the fact if the crash was widespread or just a few random incidents; there were too few Talkback reports to be significant. Now, on the flip side, we won’t be able to tell for sure if we’ve really fixed the crash unless we get significant numbers of users to move from 1.1 Beta to a nightly (and if the Talkback numbers remain low after that move).
If you are currently using 1.1 Beta and are sick of the random crashing, instead of suffering through or going back to Camino 1.0.4, please consider grabbing today’s branch nightly build and using it for a while instead of 1.1 Beta. This build has all the same features, some new bug fixes, and (hopefully) 80% fewer crashes. Your testing now will help ensure Camino 1.1 is as rock-solid as Camino 1.0 has been, and you will have the undying appreciation of the development and QA teams and hundreds of thousands of Camino users everywhere. 
Permalink
03.05.07
Posted in Uncategorized at 5:38 pm by Smokey
Some people were complaining that my feed only contained short chunks of my posts. Because of said complaints, I poked around, and, from now on, all consumers of my feed (all two of you) will be inundated by pages upon pages of text each time I write something. 
Permalink
03.04.07
Posted in Camino, Software at 12:46 am by Smokey
I was going to write a little bit about Camino 1.1 Beta, but after we got it out the door, I switched gears to pushing Camino 1.0.4, our next-to-last release of the 1.0.x series, through its final pre-release steps (expect a release sometime this week), and I also got a little distracted by working through some of the data we began receiving from 1.1 Beta. In the meantime, Stuart has written a number of nice posts about 1.1 Beta, where we are, and where Camino is headed. If you haven’t read his recent posts, be sure to check them out.
Instead of re-inventing the wheel and writing about 1.1 Beta itself, I’d like to write a little bit about one of our major sources of feedback on Camino, Talkback. Some of you are (unfortunately) familiar with Talkback, an application that runs whenever Camino crashes—hopefully this is a very rare occurrence for most of you. Talkback is Mozilla.org’s equivalent of Apple’s Crash Reporter (the ”Send a report to Apple…” button in crash dialogues), and it’s pretty good at doing certain things.
Talkback’s main strength is its ability to aggregate quantities of crash data and display this data in a (somewhat) useful format. For example, if lots of people are experiencing a crash in a certain bit of code, perhaps all when visiting the same web pages, or perhaps across a number of web pages that wouldn’t ordinarily trigger someone to think “Hey, I’m experiencing this same crash all the time,” Talkback makes it easy for us to discover this crash—even if no one on the development team has experienced it themselves. Talkback enables us to file bug reports on crashes that might otherwise not be reported, and sometimes the developers can even fix bugs just by looking at the bit of code that Talkback (sometimes) fingers as the cause.
Unfortunately, being able to figure out the problem just by looking at the code “finger-pointing” that Talkback provides is pretty rare. Sometimes there will be a good comment or comment and URL in a report indicating what the user was doing on what web page (or website) when the crash happened. These reports prove slightly more lucky for the development team; sometimes developers or QA can reproduce the crash from these comments and figure out the problem.1
Which brings me to my first point: the more data, the better. It’s always tempting to simply click through all the buttons and windows Talkback brings up (and perhaps set Talkback to send reports automatically without interrupting you), or even not to send Talkback at all. Before I started working with the Camino team, I always had Talkback just send reports without prompting me, but after I started working on triaging bugs, I realized this had been making my reports less useful. Any report is better than no report, but if you can provide the site or specific page (pull it out of History when you relaunch Camino) and a sentence or so about what you were doing when Camino crashed, it will significantly improve the chances of getting the crash fixed.
If you experience what you think is the same crash over and over (either the same general action causes a crash on different pages, or you always crash on a certain page), let us know. Drop by the forum or the mailing list, or file a bug directly. It may be that we already know about the crash and have a bug filed, or you may help us discover something that has gotten lost among other Talkback reports (Talkback sometimes—often with crashes we’re trying to fix —doesn’t point out problematic code, or groups a number of crashes under too general a section of code). In any case, being in contact with a person who is experiencing one of these common crashes will help us have a better chance of fixing it. So point two: Talkback is great, but it is no substitute for real bug reports. (Note that I said “if you experience the same crash over and over”—filing bug reports on crashes that only seem to happen once are often counter-productive, as working with those reports can divert resources from working on crashes that are common.2)
In review:
- Any Talkback report is better than no report at all.
- The more information you provide in your Talkback report (comment or URL), the more useful your report is to the developers.
- Talkback is no substitute for an actual bug report (with crash logs) for reproducible crashes.
All of which is a long way of saying “you could be the key to fixing the crash that is annoying you.”
1 My favorite example of this is bug 312062 where, after several developers and I had been combing through Talkback reports for some time, Simon Fraser was finally able to reproduce the bug after finding one Talkback report with a URL and a brief comment. Although the root causes of this bug are still un-fixed, a work-around which prevented the vast majority of the crashes was introduced into the code, making Camino 1.0 much more stable than it otherwise would have been. ↩
2 Since I’m writing about crashes, it is important to address the elephant in the room: unfortunately, as some of you have discovered, Camino 1.1 Beta shipped with a random but sometimes-frequent and always annoying crash. 
It appeared in Talkback right before 1.1 Beta, and, with the help of some users who were seeing it often, we coded a fix; the fix seemed to work, but Talkback data from Beta indicates the crash is still out there. We now have a better idea of the problem and a better fix, and we hope to have it in the nightly builds in the coming week. An unstable Camino upsets us as much—or more—as it upsets each of you. ↩
Permalink