Re: [w3ctag/design-reviews] ClipboardChange event API (Issue #1017)

Wanted to provide my initial thoughts/clarifications after reading the above mentioned two points especially this concern:

> Could you explore providing just the list of available clipboard types in the clipboardchange event, and not the full clipboard contents?


I think there is misunderstanding that clipboardchange event would provide full clipboard contents when it is fired.

As mentioned in the explainer in [5.3](https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/ClipboardAPI/clipboard-change-event-explainer.md#:~:text=Therefore%2C%20the%20only%20way%20to%20read%20clipboard%20contents%20within%20a%20clipboardchange%20event%20handler%20would%20be%20using%20the%20Async%20Clipboard%20APIs.%20Note%20that%20the%20clipboardchange%20event%20would%20still%20be%20a%20ClipboardEvent%20but%20the%20clipboardData%20attribute%20would%20be%20set%20to%20a%20null%20object)):

> Therefore, the only way to read clipboard contents within a clipboardchange event handler would be using the Async Clipboard APIs. Note that the clipboardchange event would still be a ClipboardEvent but the clipboardData attribute would be set to a null object.

So, when there is a change to clipboard, the clipboardchange event would be fired without any clipboard contents.

The web developers/apps will continue to use the already existing ways of reading clipboard which are subjected to the existing clipboard permissions that are needed to read the clipboard.

The clipboardchange event itself will need the "clipboard-read" permission to be granted on the page for it to be fired(but clipboard contents are not available when this event is fired). 

@jyasskin does this help in clarifying the concerns?



-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1017#issuecomment-2586656759
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1017/2586656759@github.com>