Idle Time

The problem

The WebKit framework that comes with Safari 4 enforces a restriction on calling WebKit from a secondary thread.

GrowlMail accesses message contents on a secondary thread because they may not be in yet. Accessing message contents can result in a call to WebKit. That results in a crash with the new WebKit.

The fix (section added 2009-04-19, updated 2009-06-22 for the 1.1.5 release)

Download Growl 1.1.5 and install GrowlMail 1.1.5.
(Make sure you install GrowlMail specifically! The Growl Installer package does not include GrowlMail or any of the other Extras.)

The workaround

UPDATE 2009-06-22: You don’t need to do this anymore. Install GrowlMail 1.1.5 instead.

If you’re fast or can easily turn off your internet connection first, go to GrowlMail’s Preferences and set GrowlMail to summary mode. (You might also try putting Mail into Offline mode immediately after launching it until you’ve made this change.)

1. Go to Mail’s Preferences.
2. Click on the chevron button at the far right end of the toolbar.
3. Click on GrowlMail.
4. Choose the second of the three radio buttons: “Show a summary of received emails”.

You can then go back into online mode/turn your internet connection back on/rest easy.

The other way to do it is to run this command in a terminal window:

defaults write com.apple.mail GMSummaryMode -int 2

Ordinarily, I’d tell you to quit Mail first, but since Mail will unexpectedly quit the first time tries to Growl about a new mail message, I don’t think I need to bother. ☺

The fix

We’re not sure about that yet.

The problem is that when Mail adds a new message to your library, it may not have fully downloaded it yet. (You can see this yourself sometimes when your internet connection is slow or under heavy load: You’ll click on a message and see a “Loading” screen in the preview pane.)

When that happens, if we try to get the message body on the main thread, it blocks the UI until the body arrives. So we do it on a secondary thread instead. That’s now a problem.

The ideal fix is that we find a way to determine whether the body has come in yet. If it hasn’t, we could set a timer for a few seconds, then check again then and post a notification with “body not loaded yet” if it’s still not in.

Another fix I would consider is simply killing the feature that shows the message body in the notification. I’m sure a lot of you like it, but if it breaks the app and there’s no fix, then it has to go.

UPDATE 2009-02-25: As it turns out, we had most of the above fix in already (except that we were using a delay, not a timer—not a problem, since it’s on its own thread). So the fix was simply to move most of the code to the main thread. I’ve done that and it works. The relevant patches are pending review; if I hear nothing bad about them from the other developers by tomorrow, I’ll make them permanent commits and push them to both repositories, where they will be part of 1.1.5.

Other points

This is not a bug in WebKit. Strictly speaking, it’s not a bug in GrowlMail, either, because it’s not like we’re disobeying the documentation for Mail’s API (there is none!).

Apple changed WebKit to throw this exception, and GrowlMail doesn’t catch it. As far as I’m concerned, it’s GrowlMail’s fault and we’re the ones who need to fix it.

Timeline? No idea. I do intend to have this fix in for 1.1.5, since Safari 4 will probably be either out or coming Real Soon Now by then. (This among other important fixes, such as the off-by-two error in the Growl prefpane.)

UPDATE 2009-06-22: The fix is in GrowlMail 1.1.5, which we released on 2009-06-16.

Categories: Growl. | Comments: 14 (feed).