Re: Safe time to add accessory view to NSSavePanel in sandboxed app?
Re: Safe time to add accessory view to NSSavePanel in sandboxed app?
- Subject: Re: Safe time to add accessory view to NSSavePanel in sandboxed app?
- From: Martin Wierschin <email@hidden>
- Date: Thu, 16 Jul 2015 12:30:43 -0700
I've also seen this crash, as reported by users of my own sandboxed app, though I've never reproduced it myself. I've also seen other situations where NSSavePanel and NSOpenPanel trigger XPC assertions/exceptions. For example:
> *** Assertion failure in +[NSXPCSharedListener connectionForListenerNamed:fromServiceNamed:], /SourceCache/ViewBridge/ViewBridge-105/NSXPCSharedListener.m:394
> NSXPCSharedListener unable to create endpoint for listener named com.apple.view-bridge
In this situation an instance of NSSavePanel simply could not be created, before my accessory view was even requested. This would deadlock my app as the NSDocument machinery tried to initiate a save operation– filed as rdar://21128102. I managed to prevent the deadlock by catching the exception, canceling the save, and alerting the user that OSX's save panel was temporarily unavailable. Not the most reassuring of error messages, but better than a hang.
There were a lot of these issues under OSX 10.9. For example -[NSRemoteView updateWindowEdgeResizingRegion] would trigger:
> <NSRemoteView: 0x7fd8bbd00000> is invalid; in: NSInternalInconsistencyException line 0.
They seemed harmless enough, but filled console logs. I haven't seen them as often lately, so hopefully things are improving.
> Is it trying to be clever and re-use existing accessory views, or is a fresh one created each time?
Why do you ask? Is this a known problem? The Apple documentation implies that it's safe, as long as you handle the memory management properly:
> If you want to reuse the accessory view, you should not rely on the panel to hold onto the accessory view until the next time you use it; instead, you should maintain your own strong reference to the view.
~Martin Wierschin
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden