Dan Wood: The Eponymous Weblog

Terry and I headed over to Macworld this morning after a bit of being annoyed at not being able to watch the keynote over the Web. By the time we arrived, the keynote was over and the Apple booth was open ... along with, of course, the rest of the show.

Overall, it looks like a good year for Macworld, in spite of the fact that the show has now shrunk to just one half of Moscone Center. The iPod Shuffles were cute, and I think they will be phenomonally successful, even more than the current line of pods. Why? Because everybody who exercises will want one. The Mac Mini looks like it would be a nice lightweight server. And Apple's software updates look good. (And, thankfully, do not conflict with the project that we are currently working on, which today we informally code-named "iFoo".)

My biggest complaint about the show, one which I'm sure many thousands of attendees would agree with me on, is the noise generated when a half-ass cover band (which I found out later was the Spin Doctors, which confirms my long-held suspicion that they are a half-ass cover band) blasted the hall with a concert, making it almost impossible to talk to people or to give or receive demos in the 4 or 5 aisles near the stage. Vendors I spoke to in the area were exasperated, and commented on the thinner crowds during the concert. Maybe these doctors of spin would be enjoyable in a different setting, but people came to Macworld there to talk Mac, not rock out!

Anybody know anybody who has any influence in deciding what special events to put on at Macworlds? These people need to know that staging a concert on an expo floor is bad business.

I have not done much "Apple Bug Report Friday" posting for a while, nor much blogging for that matter, because I am spending a huge amount of time working on Sandvox. And where I have been reporting bugs lately, it's mostly been on WebKit's Bugzilla system.

I did come across this one annoyance, via some beta-testing feedback. Sandvox currently requires Mac OS X 10.4.3 — yes, the latest update — to run. There are some fixes to Core Data that we need to take advantage of. We set the LSMinimumSystemVersion property in the application's Info.plist file. So what happens when somebody running any earlier version of Mac OS X tries to open Sandvox?

For crying out loud, tell us the minimum version that is required! This dialog makes it look like there is something wrong with the application or your system!

Reported as bug ID 4363495.

Update: Chris Campbell of Big Nerd Ranch has posted a nice little wrapper utility that warns you of the necessary system version; the wrapper works all the way back to 10.0!

Sandvox's beta program is going well ... we've expanded our list of testers by a big chunk (though there are many more people that want to be testers, but we just don't have the bandwidth to handle that many). On our latest release last week, we started getting crash reports. A lot of crash reports. And they all had pretty much the same backtrace. The topmost line in the backtrace was always:

-[WebHTMLView(WebPrivate) _recursiveDisplayRectIfNeededIgnoringOpacity: isVisibleRect: rectIsVisibleRectForView: topView:] + 68

Nothing is more annoying in debugging than a bug you can't reproduce. So we had to figure out a way to track this puppy down by remote control, analyzing the crash reports, asking friends who got the crasher to try out experiments, and so forth.

Fortunately, we have the source to WebKit — in fact, we are bundling a recent build of WebKit with the application — which is where the crash occured. But was the WebKit really to blame, or our source code? In any case, we reported it to Bugzilla. The crashes seemed to come when somebody clicked on a popup menu in the toolbar. We were using a custom object for an iconic popup button, so maybe that was to blame.

After more investigation, and more crash reports coming in, we found a few other ways that the crash occured. What was common about the crashes was the point of the crash, and that further back, the method -[NSMenu _popUpContextMenu:withEvent:forView:withFont:] was getting called. (Our popup menu was invoking this to bring up its menu, even though it wasn't strictly a contextual menu.)

The analysis of the source code made it seem like a WebView was getting deallocated. But extensive checking revealed this not to be the case. We were dereferencing a null pointer, a pointer that should not have been null.

As it happens, one of our beta testers who was getting the crash happens to be an extremely talented developer/debugger/hacker. After hours of tracing, he discovered what was happening. Some users have third-party contextual menu plugins installed that link to WebKit. (The most popular of these seems to be the one that comes bundled with Graphic Converter.) So what was happening was that when somebody brought up a contextual menu, the plugins were loaded; one that linked to WebKit brought in the system's version of Webkit, clobbering our bundled WebKit. And boom, the crash.

The next step is how to deal with this. For now, we are scanning the contextual menu plugins ourselves to find those that link to WebKit, and warn our beta-tester of the incompatibility. But what we are really hoping for is a way to prevent these bundles from loading, and/or prevent them from loading in the system's WebKit that would link to our own. We have a technical support incident pending with Apple....