[Openmcl-devel] CCL Issue with Lion

[Michael Minerva]

Hey Gary,

Thanks a lot for your response.

On May 2, 2013, at 6:19 PM, Gary Byers <gb at clozure.com> wrote:

> The behavior that you describe seems similar to that described in:
> 
> <http://stackoverflow.com/questions/10508522/nsopenpanel-doesnt-show-when-i-call-runmodal>
> 
> where the problem apparently had to do with (lack of proper) "entitlements".  (The owner of the
> appliance - quaintly referred to as the "user" in some documents - might try to access the filesystem
> on their "computer" otherwise.)
> 

I believe this is not the same issue I am dealing with.  We have enabled the entitlement that he is referencing in this post.  Here is our entitlements plist for the file I sent:

<plist version="1.0">
<dict>
	<key>com.apple.security.app-sandbox</key>
	<true/>
	<key>com.apple.security.files.user-selected.read-write</key>
	<true/>
	<key>com.apple.security.network.client</key>
	<true/>
</dict>
</plist>

The com.apple.security.files.user-selected.read-write is the entitlement he references in his post which allows the user to select a location where the application can read and write. 

> I have no idea why this would work on some systems that support sandboxing and not on others,
> but I confess that I had some difficulty parsing your message.  (There's more reason to think that
> this is a Lion problem than that it's a Mountain Lion problem, but I don't know how anyone would
> know for sure.)
> 

Sorry if my message was unclear, just to be sure, we have tested this on 3 machines with Mountain Lion and 2 machines with Lion, and so far, the dialog would not show up on any of Lion machines and it showed up on all of the Mountain Lion machines. While this is not a comprehensive test, this does indeed seem to be a Lion only problem. 

> There's no reason to think that this is not a CCL problem.  There's no reason to think that it is a
> CCL problem, either.  If a sandboxed ObjC program with exactly the same entitlements behaved
> differently, then there'd at least be some reason to wonder why Cocoa methods called from CCL behave
> differently than they do when called by that ObjC program.  My model of things is that those Cocoa methods
> don't know or care what programming language their callers were compiled in, and I don't know of any 
> reason to think of that model as being incorrect.
> 

I have created a Sandboxed ObjC app with the same entitlements and tested it on Lion and Mountain Lion machines and the dialog always pops up. The app simply has a button hooked up to an IBAction that creates the NSOpenPanel when it is pushed. I tried the exact same cocoa code in sandboxed CCL on Lion and the dialog does not pop up.  

Here is the IBAction:

- (IBAction)openDialog:(id)pId
{
    NSOpenPanel *panel = [[NSOpenPanel alloc] init];
   [panel runModal];
}

After creating the app I verified that it had the same entitlements with:
 codesign -dvvv --entitlements :- /Users/Mike/Library/Developer/Xcode/DerivedData/DialogTest-cavpxfrvxshnnmdiqxjdocldarco/Build/Products/Debug/DialogTest.app 

and it did indeed have the same entitlements:

PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>com.apple.security.app-sandbox</key>
	<true/>
	<key>com.apple.security.files.user-selected.read-write</key>
	<true/>
	<key>com.apple.security.network.client</key>
	<true/>
</dict>
</plist>
> Googling for "sandbox NSOpenPanel" indicates that many people have found that these things don't
> interact as people expect them to and as the documentation suggests that they should, and that this
> is often due to bugs in the underlying technology.   Some messages that one can easily find via that
> Google search suggest that the forums on Apple's developer site offer a better explanation of what works
> and what doesn't than one can easily find elsewhere.

This is a good suggestion and I have found a lot of good stuff on the Apple Developer boards but I do not know if it would be much help on this issue which does not seem to occur with a similar Xcode project.

--Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20130503/0dc89bd3/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2559 bytes
Desc: not available
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20130503/0dc89bd3/attachment.bin>