User Profile

Quinn; Thanks for your reply. Yeah Numbers works somewhat better but there are issues…. First I don’t have any need for the actual file to be returned via AppleScript.   I cannot predict how large a given file might be… So using Numbers file property of the document object, if I return only the POSIX path of the file object - I do get different behavior than with the returned path string from TextEdit.. My app takes the AppleScript result and constructs a custom attributedString that embeds the fileURL… When the user clicks on this attributedString (from Numbers) in the app’s main textView, I don’t get the error: [sandbox] Sandbox extension creation failed: client lacks entitlements? for path: Instead a Finder view opens to the enclosing folder without any complaining in the console - better yes, but not what I expect! I expected the file to actually open… But this ‘enclosing folder’ behavior is something I observe with a number of different ‘click on link’ actions - it seems that the ’System’ is forcing the user to perform the specific action to open a file rather that performing that open when the user only implies ‘open that file’… The user can build a collection of these text selection actions - the main attributes are stored in a custom CoreData repo. The use of CoreData is another reason why returning the file is not the correct result - I don’t want to store randomly large files in CoreData when all I want is a fileURL…. When I quit and relaunch the app, clicking on the attributedString results in the same Finder behavior but now the error mention above is shown in the Console. So the sandbox permission is very short lived - it only lasts for the current session…. From my perspective this is a limitation of the sandbox - If the user correctly asked me to access a file - why does that permission not persist if none of the security constraints have changed? Sure I do understand that there are issues -  but I am trying to articulate the limitations I experience in app development… So the whole POSIX thing above let to experimentation with the AppleScript in TextEdit. On the whole I don’t find a better solution than simply returning the path string and using it in the attributedString mentioned above. In this case, the click action will throw this error to the console but will also open the enclosing folder as above. The user’s experience is identical to what happens with the file object from the Numbers script….

Quinn; Thanks for this response. Also thank you for your long standing service to the developer community!! I wish there were a dozen of you. The URL is established by simply asking the active app for its current document. First recall that I have the app level entitlement: com.apple.security.files.user-selected.read-write On launch my app becomes an observer of 'externalApplicationDidActivate' et al - in this fashion my app is aware of the active app. When the service is invoked my app may fire a compiled AppleScript. These AppleScripts targets (~25) are each approved with an entitlement (com.apple.security.temporary-exception.apple-events) as well as each of these targets being approved by the user using the 'AEDeterminePermissionToAutomateTarget' mechanism These scripts are about as simple as can be; an example is shown below. I suppose that this fits the 'constructed internally' paradigm you reference above but I submit that it complies fully with the 'System' - I don't see how I can make it more fully comply with the 'System'. If you are aware of a better mechanism - I am all ears! So in essence the user has expressly asked my app to process a text string from a given app that my app has ensured that the system understands that my app will interact with.. Why under these circumstances are the results of a valid AppleScript from an approved app not considered as supplied by the 'System'? Any thoughts you might have will be fully considered! Thanks Again for your time and your patience over many years! Steve tell application "TextEdit" try set documentName to name of document 1 set documentPath to (path of document 1 as string) if ((documentPath is missing value) or (length of documentPath is 0)) then set documentPath to "unsaved document" end if set theResult to {|url|:documentPath, title:documentName} on error errMsg number errNum set theResult to {title:("Error" & errNum as text), |url|:errMsg} end try end tell return (theResult as record)

Done. FB9964644

the answer is embedded in the exception text "...Key path: count". I had somehow turned On a xib binding to "mutA2.count". Removing this cleared up the matter

Etresoft; Thanks for contributing to this discussion and filing a bug report. You said: "...If this is really a Safari problem, then my suggestion would be to add HTML to your data types. RTF is pretty ubiquitous on macOS, but isn't the future. There is no guarantee that new code is going to support RTF like it has in the past. It does still say "NeXT", after all...." So the answer is provided in my earlier log. Safari does NOT provide html to a service! For extra credit I DID enhance my app to acquire html data but unsurprisingly it is null. If you look at the log you will see that the "pboard.dataTypes" reported in the service entry point are: "public.rtf",     "NeXT Rich Text Format v1.0 pasteboard type",     "public.utf8-plain-text",     NSStringPboardType,     "com.apple.flat-rtfd",     "NeXT RTFD pasteboard type",     "public.utf16-external-plain-text",     "CorePasteboardFlavorType 0x75743136" So there is clearly a bug here. Safari reports "public.rtf" but does not provide that data to the service!

Hey TyngJJ & Etresoft! Thank-you both for your help and thoughts here!! I REALLY appreciate it! So the NSService 3 SendTypes are: 'com.apple.flat-rtfd', 'public-rtf', and 'public.plain-text' These have not changed over the course of time but the service entry point results have changed. So I took the app to Big Sur to compare with Etresoft's findings. At this point it seems to be application related... Safari is NOT providing rtf in the service on either Calatina or Big Sur. Here's some Big Sur logging from the service entry point shown earlier when the text selection is RTF First you see Text Edit then Safari.... So, Etresoft if you are still listening and inclined please test with using Safari as the source application which is providing an rtf text selection.... TEXTEDIT * 2020-10-09 13:27:56.621448-0700  - BID:com.apple.TextEdit 2020-10-09 13:27:56.621599-0700  - pboard:(     "public.utf8-plain-text",     NSStringPboardType,     "public.rtf",     "NeXT Rich Text Format v1.0 pasteboard type",     "public.utf16-external-plain-text",     "CorePasteboardFlavorType 0x75743136" ) 2020-10-09 13:27:56.621651-0700  - pboard RTFD:(null) 2020-10-09 13:27:56.622996-0700  - pboard RTF:{length = 2131, bytes = 0x7b5c7274 66315c61 6e73695c 616e7369 ... 49207365 6e64207d } 2020-10-09 13:27:56.623128-0700  - pboard public.rtf:{length = 2131, bytes = 0x7b5c7274 66315c61 6e73695c 616e7369 ... 49207365 6e64207d } 2020-10-09 13:27:56.623595-0700  - pboard String:{length = 716, bytes = 0x0909596f 75206e65 65642074 6f206564 ... 20492073 656e6420 } 2020-10-09 13:27:56.623717-0700  - [pboard pasteboardItems]:(     "<NSPasteboardItem: 0x600000eb64c0>" ) 2020-10-09 13:27:56.623800-0700  - pasteboardItem[0]:(     "public.utf8-plain-text",     "public.rtf",     "public.utf16-external-plain-text" ) 2020-10-09 13:27:56.623901-0700  - pI RTFD:(null) 2020-10-09 13:27:56.624014-0700  - pI RTF:{length = 2131, bytes = 0x7b5c7274 66315c61 6e73695c 616e7369 ... 49207365 6e64207d } 2020-10-09 13:27:56.624094-0700  - pI public.rtf:{length = 2131, bytes = 0x7b5c7274 66315c61 6e73695c 616e7369 ... 49207365 6e64207d } 2020-10-09 13:27:56.624189-0700  - pI String:{length = 716, bytes = 0x0909596f 75206e65 65642074 6f206564 ... 20492073 656e6420 } 2020-10-09 13:27:56.624979-0700  - sender:com.apple.TextEdit NSPasteboardTypeRTF:2131 SAFARI * 2020-10-09 13:28:15.270898-0700  - BID:com.apple.Safari 2020-10-09 13:28:15.271097-0700  - pboard:(     "public.rtf",     "NeXT Rich Text Format v1.0 pasteboard type",     "public.utf8-plain-text",     NSStringPboardType,     "com.apple.flat-rtfd",     "NeXT RTFD pasteboard type",     "public.utf16-external-plain-text",     "CorePasteboardFlavorType 0x75743136" ) 2020-10-09 13:28:15.272557-0700  - pboard RTFD:{length = 0, bytes = 0x} 2020-10-09 13:28:15.273071-0700  - pboard RTF:{length = 0, bytes = 0x} 2020-10-09 13:28:15.273242-0700  - pboard public.rtf:{length = 0, bytes = 0x} 2020-10-09 13:28:15.273731-0700  - pboard String:{length = 621, bytes = 0x310a596f 75206e65 65642074 6f206564 ... 652c2074 68656e20 } 2020-10-09 13:28:15.273921-0700  - [pboard pasteboardItems]:(     "<NSPasteboardItem: 0x600000e10a80>" ) 2020-10-09 13:28:15.274031-0700  - pasteboardItem[0]:(     "public.rtf",     "public.utf8-plain-text",     "com.apple.flat-rtfd",     "public.utf16-external-plain-text" ) 2020-10-09 13:28:15.274170-0700  - pI RTFD:{length = 0, bytes = 0x} 2020-10-09 13:28:15.285873-0700  - pI RTF:{length = 0, bytes = 0x} 2020-10-09 13:28:15.286083-0700  - pI public.rtf:{length = 0, bytes = 0x} 2020-10-09 13:28:15.286269-0700  - pI String:{length = 621, bytes = 0x310a596f 75206e65 65642074 6f206564 ... 652c2074 68656e20 }

Etresoft; Try recompiling that old app using Xcode 12 on macOS 10.15 and run again. Using an old binary doesn't get to the issue.

TyngJJ ClipboardViewer does not provide an option for viewing the NSPasteboard that is presented to a Service using the above entry point... So it is not helpful in this circumstance. With further research what I currently see is this: On macOS a user can make a text selection in a given application and then use 1 of four 'direct' means of invoking a second application to act on that text selection. (I use 'direct' here to mean that the selection is not saved to the file system in some fashion and then this file is acted on by the second application) The 4 mechanisms are: drag the text to a window managed by the second application drag the text to the dock icon of the second application invoke a 'Service' by using one of the various menus which are available for 'Services' (the service is provided by second application) invoke a keyboard shortcut associated with the second application It used to be that these means would all yield the same RTFData. This is no longer true. The 2 drag mechanisms still yield the expected RTFData The 'Service' and keyboard shortcut do NOT yield an RTFData (they do yield an NSPasteboardTypeString product) Please note that the keyboard shortcut is a user interface convenience which in fact utilizes the 'Service'... The upshot here is that what has changed is the 'pboard' in the standard service entry point: (void) xyzService:(NSPasteboard *)pboard userData:(NSString *)userData error:(NSString **)error; { This NSPasteboard no longer behaves as it did in the past! Can someone please point me to where this change in functionality is documented! Thanks!

Apologies for the formatting above.... Didn't see this until just now... In any case should be: // this is a standard service entry point (void) xyzService:(NSPasteboard *)pboard userData:(NSString *)userData error:(NSString **)error; { ... NSData *rtfData=[pboard dataForType:NSPasteboardTypeRTF];    if (rtfData!=nil) { ... } ... }

At 7:20 pm PDT 9/3/2020 I tried the receipt validation in main.m as was originally in place. Worked as designed! Methinks something was changed on the backend... Thank-You to everybody involved.

Per DTS request above I have filed: FB8620384 at ~3pm PDT 9/3/2020

Folks; Some further data because I just know you were all waiting on the edge of your seats! So I defer the receipt validation which normally occured during main.m. When a SKReceiptRefreshRequest is issued it errors out with a strange error: Error Domain=SKErrorDomain Code=0 "(null)" UserInfo={NSUnderlyingError=0x600000d2a250 {Error Domain=com.apple.commerce.client Code=500 "(null)" It 'feels' like something has changed recently in Catalina... This all used to work! I'm stuck here - I have a bug fix to get into the App Store but the only way I can see to do that is to remove all the receipt handling because it no longer works. This stinks! Can someone please point me to some useful information? Please! Steve