{"id":41736,"date":"2024-01-10T15:38:08","date_gmt":"2024-01-10T20:38:08","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=41736"},"modified":"2024-10-09T15:39:38","modified_gmt":"2024-10-09T19:39:38","slug":"mac-app-sandboxing-interferes-with-drag-drop","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2024\/01\/10\/mac-app-sandboxing-interferes-with-drag-drop\/","title":{"rendered":"Mac App Sandboxing Interferes With Drag & Drop"},"content":{"rendered":"

Wade Tregaskis<\/a>:<\/p>\n

\n

Merely inspecting the UTIs in the pasteboard is fine – that doesn’t interfere with anything. So if all you care about is if any<\/em> kind of file (or folder) is being dragged, you’re set. But if you want to only react to some<\/em> types of files or folders, you need to know more.<\/p>\n

If you ask for the URL – even without actually using<\/em> it – you trigger some behind the scenes activity involving app sandboxing. This prevents the file being made accessible to your app if & when it actually is dropped into your app.<\/p>\n

When things are working correctly<\/em>, when a file is dragged and dropped onto a receptive view in your app a link to that file is created inside your own app’s container. It’s that link<\/em> that you actually have access to – the original file cannot be accessed directly. That link seems to persist for a while – perhaps until your app is quit – so once you have it you’re set.<\/p>\n

I don’t know why merely peeking at the file path (URL) prevents this link being created, but it does.<\/p>\n<\/blockquote>\n

Previously:<\/p>\n