Re: [w3c/clipboard-apis] `changeId` interaction between `clipboard.write` and `clipboardchange` (Issue #243)

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

I think "self" in this context is what you describe. Or another way of thinking about it is that if a site has a way of knowing about the clipboard change without requiring the event, then the event isn't necessary. Though I'll also point out that suppressing the event for self-initiated writes is only one possible solution, and I'm not convinced that it's the best one. At a minimum that behaviour would need to be documented in the spec.

> is the simplest javascript solution—making site's first `clipboardchange` handler call after calling `write()` back up the new `changeId` without syncing clipboard to remote—not sufficient?

For any interaction between `clipboard.write` and `clipboardchange` to work, I think we need to assume that the same code is handling both. In the case of Chrome Remote Desktop, that code basically looks like this:
```ts
const isDuplicate =
  // If the changeIds match then this is definitely a duplicate.
  previousChangeId === changeId ||
  // If previousChangeId is unset then compare the content.
  (!previousChangeId && content === previousContent);
if (!isDuplicate) {
  previousChangeId = changeId;
  previousContent = content;
  ...
}
```
Where `previousChangeId` gets reset on `clipboard.write()`. I think your proposal basically boils down to skipping the content check. It will work, as long as we can guarantee that the first `clipboardchange` event received after `clipboard.write()` corresponds to that write. It's not obvious that that's the case, but I think in practise it's safe--not just because of the coincidental timing required for it to break, but also because both `clipboard.write()` and `clipboardchange` require the page to have focus, and the OS clipboard generally isn't updated by applications that don't have focus (though this isn't universally true--some clipboard managers update the clipboard in the background). The only caveat is that this approach only works if `clipboardchange` events _are_ delivered for self-initiated writes, so perhaps the spec ought to state that if we believe that this should be the recommended way of detecting them.

In the case of Chrome Remote Desktop, the actual code is a bit more complicated because we check the clipboard on `focus` if `clipboardchange` isn't supported. Since we have to check the content in that scenario anyway we'll probably do so after `clipboard.write()` as well.

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

Message ID: <w3c/clipboard-apis/issues/243/3407739687@github.com>