macOS 下程序监视剪切板不需要任何权限的吗?
如果你希望按进程控制剪贴板的权限,首先要做的是把所有“默认可以让用户粘贴”的文本框都由操作系统的特殊进程提供,并跨进程合成完整 UI 。这仍然不能解决复杂文本编辑器第一次粘贴需要被打断的问题。
举个例子:在 macOS 里,如果你用“打开”对话框导航到 Documents,并且拒绝提供权限,那么“打开”对话框无法显示里面的内容。在 Windows 里,如果 UWP 用 FileOpenPicker,它不需要具有访问本地文件系统的权限也可以让用户自由选择该用户有权限访问的内容。这个区别在于,macOS 里每个 app 的“打开”对话框都是进程内代码,自然不能访问被拒绝的文件夹;而 Windows UWP 里的“打开”对话框是一个专门的进程(该进程有权限访问文件系统,并且可以把权限提供给 UWP )完成的,该进程确保打开文件是用户自己的操作。
在文本框的例子里上述解决方案仍然不好,因为通常一个 app 可以要求自己的文本框执行一些操作,那么它可以要求文本框粘贴,然后读取内容。此外,进程隔离仍然不能解决复杂、非系统实现文本框的粘贴问题。
当然无论是 NSOpenPanel 还是 FileOpenPicker 都不能阻止应用自己读文件然后画一个假的对话框。
程序想自己画对话框和安全问题无关,UWP 无法自己读文件然后自己画对话框,它通常没有权限读文件系统。
我倒是很好奇你说的“无法显示 Documents”的是哪个应用。这听起来像是自己读文件画的对话框(受限于沙盒读不到)。但是沙盒应用搞这种乌龙听起来实在可疑。