4 ms·
The app might be implementing the paste function. The most common use case of copying and pasting text could probably be hidden inside the standard text fields,
by jws 7y ago
The app might be implementing the paste function. The most common use case of copying and pasting text could probably be hidden inside the standard text fields, but consider images, sounds, or custom data types. The app needs to grab these off the clipboard and do something with them and will be triggering the action from some custom user interface element. Even for text, a terminal emulator or word processor is not going to be using a standard text field as the target.
Most apps could probably live happily with there being an entitlement for ‘unsecured clipboard access’ to enable anything but text into a text field.
- _bxg1 7y agoThe OS could provide a dedicated button of its own for pasting images, etc. It could be recognizable and standard and apps could embed it as needed. The key is that apps shouldn't have silent, arbitrary clipboard access. The user should have to do an action for the clipboard's contents to be transferred. The only way to prevent abuse is for a system-provided widget to be the one making the actual API call. Another option would be to provide apps an API call that opens a system "paste dialog", asking the user, "Paste X into this app?". This would have the added bonus of giving the user a preview of what they have in their clipboard before actually performing the paste. It could even show a history of the last several copied items in case they want to paste one of those instead, which would be a genuine productivity-booster.
- m463 7y agoApple could require the paste dialog before the clipboard was accessed. Complicated buffer access would require an "allow" dialog. I am probably oversimplifying things.
- mirimir 7y agoThe app doesn't need to grab anything until the users selects paste. The added latency would be miniscule.