Re: [w3c/clipboard-apis] Proposal: Identifying whether the clipboard has changed without re-reading it (Issue #232)

jamiewalch left a comment (w3c/clipboard-apis#232)

lukeklimek suggested commenting here with my use-case in favour of adding some sort of UUID, either to the `clipboardchange` event, or to `navigator.clipboard.read`. I've also written this up at https://g-issues.chromium.org/issues/434025175.

In a multi-window app, each window needs to listen for `clipboardchange` because it's only delivered to the foreground window and the app needs to see the event regardless of which window has focus. That means that an app with two windows will typically receive two events for each clipboard change--one per window when that window gains focus. De-duping based on content is a workaround, but it won't handle the case where the user copies the same content to the clipboard twice. Specifically, without a UUID, it's impossible to tell whether or not step 3 occurred in the following:

1. Copy `foo` to the clipboard from some other app
2. Select window A
3. (maybe) copy `foo` to the clipboard again
4. Select window B

This is a problem in some scenarios. For example, it's a fairly common thing to do in remote desktop applications if the local and remote clipboards gets out-of-sync.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/clipboard-apis/issues/232#issuecomment-3152257898
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/clipboard-apis/issues/232/3152257898@github.com>