Re: [w3c/clipboard-apis] Async clipboard read and race conditions. (Issue #180)

The Web Editing Working Group just discussed `async clipboard read & race conditions`.

<details><summary>The full IRC log of that discussion</summary>
&lt;Travis> Topic: async clipboard read &amp; race conditions<br>
&lt;Travis> github: https://github.com/w3c/clipboard-apis/issues/180<br>
&lt;Travis> snianu: we looking to figure out if the clipboard content changes between reading system clipboard and santization step... should we just return the content read from the clipboard, throw an error, or return empty clipboard.<br>
&lt;Travis> .. macOS, iOS have limits as noted by whsieh in the issue.<br>
&lt;Travis> Travis: do you have a preference?<br>
&lt;Travis> snianu: came up while working on image sanitization... encode/decode takes some time.<br>
&lt;Travis> .. when the author makes the read call, the user gave them permission.<br>
&lt;Travis> .. at that moment, the user is expecting the data in the clipboard.<br>
&lt;Travis> .. I think it makes sense to return the data (not throw)<br>
&lt;Travis> .. what if the user switches to another apps, puts something else on the clipboard?<br>
&lt;Travis> .. if the browser already read the data, then the clipboard content could have changed.<br>
&lt;Travis> .. currently (in chromium) plan is to return an empty image.<br>
&lt;Travis> .. we could also throw a data error.<br>
&lt;Travis> Travis: interesting that the plan is to return an empty image.<br>
&lt;Travis> .. what to do with non-image cases?<br>
&lt;Travis> whsieh: I think we should try to match behavior of other apps on the system (for copy/paste)<br>
&lt;Travis> .. this isn't a common scenario.<br>
&lt;Travis> .. might be able to craft an image to take a lot of time to decode and switch...<br>
&lt;Travis> .. in that sense, it probably affects images more than other types (like markup)<br>
&lt;Travis> .. Always possible to hold a clipboard item and re-read it over and over...<br>
&lt;Travis> .. wondering what web author expectation is?<br>
&lt;Travis> .. expect authors to be prepared to handle exceptions.<br>
&lt;Travis> travis: returning old data (original data post processing) sounds good to me.<br>
&lt;Travis> whsieh: Q: if the change occurs before the first raw clipboard read, then what happens?<br>
&lt;Travis> snianu: In Chromium we read all the data at once... I see the issue because with delayed rendering, we don't want to do that...<br>
&lt;Travis> whsieh: In a delayed world, might make sense to throw an error. Other actions might lead to unpredictable behavior (depending on whether you've read the raw data or not)<br>
&lt;Travis> snianu: Sounds good.<br>
&lt;Travis> smaug: There's always a possibility of a race condition.<br>
&lt;Travis> snianu: So, will resolve to throw an error in this case.<br>
&lt;Travis> whsieh: Might be interesting to test this for interop as well.<br>
&lt;Travis> .. having the platform stomp over the clipboard content.<br>
&lt;Travis> .. we should continue thinking about that.<br>
</details>


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

Message ID: <w3c/clipboard-apis/issues/180/1212140135@github.com>