- From: Rakesh Goulikar <notifications@github.com>
- Date: Mon, 17 Feb 2025 00:22:33 -0800
- To: w3c/clipboard-apis <clipboard-apis@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/clipboard-apis/issues/232/2662367800@github.com>
ragoulik left a comment (w3c/clipboard-apis#232) I acknowledge the contentsId helps in the remote desktop scenarios to determine clipboard changes by a webapp itself to be efficient and avoid multiple updates due to a single change. But I believe we should figure out a way to include this within the clipboardchange event API for following reasons: 1) ContentsId API and ClipboardChange event API have considerable amount of overlap in terms of what functionality can be acheived. And from security/privacy concerns this has same security overhead, as polling for contentsId every millisecond is same as firing ClipboardChange event. 2) To determine if a clipboard has changed, with contentsId, we encourage developers to adopt a polling mechanism (time based or event based) - which is not efficient vs firing an event when there is a change detected by Operating system. Please note that all Operating systems today provide an API to detect clipboard change without having to resort to polling. Except for MAC, where we will have to rely on detecting changes on ['changeCount (UIPasteBoard class)'.](https://developer.apple.com/documentation/uikit/uipasteboard/changecount?language=objc) This comes down to a question: Should we poll on all OSes Vs Poll on OSes where change event is not supported, that is should we support polling initiated by developers using javascript on all OSes Vs Polling only on MAC internally. So I believe clipboardchange event should be efficient and useful. 3) For the dynamically changing context menu usecase (where menu options or right click options can be shown to users based on type of content available on clipboard), developers would still need to read the clipboard using async clipboard APIs to know the available MIME types. While this works for chromium based browsers(having permissions) but implementing this usecase would not work for Firefox and Safari as there will be a 'paste button' user will have to interact with. So just knowing the contentsId is not helpful for this usecase as it does not help in avoiding user intervention. Whereas, firing an event on clipboardchange with available datatypes can help acheive this. -- Reply to this email directly or view it on GitHub: https://github.com/w3c/clipboard-apis/issues/232#issuecomment-2662367800 You are receiving this because you are subscribed to this thread. Message ID: <w3c/clipboard-apis/issues/232/2662367800@github.com>
Received on Monday, 17 February 2025 08:22:37 UTC