MarsEdit 3.5.5 is now available on the Mac App Store and directly from the Red Sweater Store. This is a free update for licensed MarsEdit customers.

This release is primarily of interest to customers with Retina MacBook Pro computers: all of the toolbar icons and other incidental art has been updated to appear crisp and beautiful on HiDPI displays.

MarsEdit 3.5.5

• Updated graphics to support Retina MacBook Pro
• Fix a bug that prevented the port number from being included in Host: HTTP header
• Fix a bug that caused drag-and-drop to margins of editor to reload the content of editor with bogus data
• Fix a bug that could crash the app when customizing toolbar items
• Fix a bug that crashed when editing tags with VoiceOver enabled
• Fix view-tabbing cycle in the blog settings panel

If you notice anything out of place, especially relating to the new Retina graphics, please let me know.

OK, I know I said I wasn’t particularly going to be supporting the Subscribe to Feed Safari extension I released last week, but it so happens I got a lot of great feedback and even some anonymous code contributions to help beef up the behavior of the plugin.

If you already have 1.0b3 or later installed, you can just check for updates in Safari’s extension preferences. Otherwise, download directly by clicking the name below:

Subscribe to Feed 1.0b4

• New toolbar icon with Retina display support
• Support for multiple feeds on a page, selectable from a popup menu
• Convert from http:// to feed:// for faster, streamlined subscription process
• Expand the list of MIME types recognized as valid feeds to cover edge cases

Hope you enjoy these fixes and enhancements. Let me know if there are other glaringly missing features or bugs.

Mac OS X’s centralized Address Book empowers developers to offer users features that go above and beyond what would be possible in the absence of such a resource. For example, an envelope-printing utility on Mac OS X doesn’t need to demand that you painstakingly type in the name and address of your friend before mailing a letter, you can search for them and automatically select from a list of matching addresses. It’s magic, it just works, and it makes a Mac a Mac.

Many other examples of Mac software just working are also based in accessing the Address Book, but instead of needing access to the whole thing, it’s just the “Me” card that is of interest. This is very useful for example if a map app wants to offer you easy directions home. A very common use case for accessing the “Me” card is when an application has good reason to pre-populate personal fields in an inquiry form of some kind: for example, a feedback or crash reporter dialog. In this case, putting the user’s email address in the field for them saves a step and prevents a possible typo.

Starting in Mountain Lion 10.8, Apple has dramatically increased security protections around the contents of users’ Address Book data. On the face of it, this is a good thing, as it protects against applications that either surreptitiously or stupidly access and upload the contents of address books to web servers without permission. The flip side is that fairly innocuous requests for the “Me” card are now met with a foreboding dialog:

Yikes! What is Red Sweater Crash Reporter and why does it want my contacts!? Sounds fishy. In fact, all it wants is the “Me” card, but there’s no way for it to let the user know this. Or is there?

Thanks to Cabel Sasser’s tweet today, I learned that there is in fact a way to express intent, albeit with a very crude mechanism. You can’t specify intent on a call-by-call basis, but you can publish in your application’s Info.plist a single string that will be conveyed to the user as an explanation for your need of Address Book data. The key is NSContactsUsageDescription, and it’s very lightly documented in Apple’s Info Property List Key Reference:

NSContactsUsageDescription (String – OS X). This key contains the localizable description of the reason why an app is requesting access to the user’s contacts information in the Address Book database.

It would be far preferable if there were an API mechanism through which an app could request specific content from the Address Book, along with a dynamically stated explanation. But this is better than nothing. Tweaking my crash reporter’s Info.plist, I end up with this:

Incidentally, if you’re a developer trying to add this to your own app, you’ll find it frustrating that the nature of this dialog provides you only one chance to get the terminology right. As soon as you click “OK” or “Don’t Allow”, that’s the last time you’ll ever see this dialog. Unless you happen to know about this magic little command line incantation (thanks to Jim Correia for reminding me):

% tccutil reset AddressBook

That clears out all permissions for your Address Book access, causing the panel to appear again the next time any app, including yours, tries to access contacts.

Before Mountain Lion 10.8 shipped, I had received reports from one customer that MarsEdit was crashing each and every time he attempted to access the network. For an app like MarsEdit whose entire raison d’être is to access the network, this is quite an unfortunate obstacle.

The public release of Mountain Lion has only confirmed that the problem, while rare, is significantly wide spread that I’m sure it affects at least dozens of my customers, hundreds of the customers of my colleagues, and probably thousands of Mac users worldwide.

The tell-tale sign of this crash is it occurs only as the app attempts to connect to some network resource, and the crashing thread always culminates in some stack trace involving CoreSchedulingSet or EmptyCoreSchedulingSet C++ objects.

Here’s one example, with just the crashing thread a few stack frames deep:

Thread 1 Crashed:: Dispatch queue: com.apple.root.default-priority
0  com.apple.CFNetwork              0x00007fff8d26cc92 CoreSchedulingSet::
			copyWithUpdatesReleaseSelf(CoreSchedulingSet
			const*, CoreSchedulingSet const*) const + 104
1  com.apple.CFNetwork              0x00007fff8d26c995
			CoreSchedulingSet::copyWithAdditionReleaseSelf(__CFRunLoop*,
				__CFString const*) const + 71
2  com.apple.CFNetwork              0x00007fff8d2cfac6
			__executionContextSchedule_block_invoke_0 + 44

And another, where the non-main thread crashes in an EmptyCoreSchedulingSet destructor:

Thread 3 Crashed:: Dispatch queue: com.apple.root.default-priority
0  libsystem_kernel.dylib            0x00007fff8d089212 __pthread_kill + 10
1  libsystem_c.dylib                0x00007fff913b2b34 pthread_kill + 90
2  libsystem_c.dylib                0x00007fff913f6dfa abort + 143
3  com.apple.CFNetwork              0x00007fff8fd8c928
			EmptyCoreSchedulingSet::~EmptyCoreSchedulingSet() + 60

Google searches, and some chat I’ve seen on Twitter, suggests the problem is certainly not limited to MarsEdit. Even Safari is vulnerable to these crashes in the affected configurations.

So what are the affected configurations? I’m not sure. Anecdotally, it seems like you’re more likely to see the problem if you are connecting in an institutional network such as a school or a large company. One customer also mentioned that he crashes when connecting through the Thunderbolt ethernet adaptor, but is able to connect without issue through the WiFi interface for his Mac.

I am posting this here in an attempt to document the known symptoms and scenarios for this crash, in case it helps other developers and customers who run into the issue.

I hope that Apple will issue a fix for this in 10.8.1, if not sooner. It sounds like this is affecting an awful lot of customers and as far as I know there is no workaround, short of changing the circumstances of how you are connecting to the internet by using a different interface or moving to a different location.

Update: I am now convinced by putting the pieces together and correlating my experiences with those of folks including the support crew at Agile Bits, that this is issue is related specifically to the “Auto Proxy Discovery” and “Automatic Proxy Configuration” settings in Network preferences. If you have one of these options checked, you are very likely to crash in MarsEdit, Safari, Tweetbot, and any number of other apps that rely on Apple’s networking libraries.

I recommend turning off the Auto Proxy Discovery and Automatic Proxy Configuration features in 10.8 unless you are on a network where using them is strictly required.

Click here for detailed instructions.

In light of the apparent link to a commonly used proxy configuration, and the growing number of apps confirmed as affected by this issue, I am hopeful that we’ll see a fix from Apple sooner than later.