Re: [w3c/clipboard-apis] What happens if promises to Blobs are not resolved within a reasonable amount of time? (Issue #161)

The Web Editing Working Group just discussed `What happens if promises to Blobs are not resolved within a reasonable amount of time? (#161)`.

<details><summary>The full IRC log of that discussion</summary>
&lt;Travis> topic: What happens if promises to Blobs are not resolved within a reasonable amount of time? (#161)<br>
&lt;Travis> BoCupp: snianu added promises to dom strings or blobs so that clipboard could take a promise to its data in a write.<br>
&lt;Travis> .. we were hearing feedback about the open-ended-ness of the promise? How long do we wait?<br>
&lt;Travis> .. 2 seconds? a minute? indefinitely?<br>
&lt;Travis> .. other issues: what if a second write happens? Is the first canceled? What about a write in another tab (across origin)?<br>
&lt;Travis> .. is it what's in the foreground that takes precedence?<br>
&lt;Travis> .. is it a matter of luck?<br>
&lt;Travis> .. lots of corner cases!<br>
&lt;Travis> whsieh: this is shipping.<br>
&lt;Travis> .. out behavior is: no hard-coded timeout...<br>
&lt;Travis> .. but if you leave the tab, the promise (prior call) is rejected.<br>
&lt;Travis> BoCupp: If the tab leaves the foreground, or a second write occurs in the same time, this rejects the previous write promise.<br>
&lt;Travis> whsieh: yes.<br>
&lt;Travis> .. furthermore, you need to be the foreground tab in order to use this; otherwise it rejects immedatiatly due to no user ineraction.<br>
&lt;Travis> .. if you switch away, then use another site to try to write to the clipboard; the subsequent write would kill the original.<br>
&lt;Travis> BoCupp: We had one mild concern.. fast-finger copy-tab-switch-paste...<br>
&lt;Travis> .. if this switch that cancels isn't fast enough...<br>
&lt;Travis> whsieh: yeaaaaah, I see that. In practice, not a concern.<br>
&lt;Travis> BoCupp: I like the rules you noted whsieh<br>
&lt;Travis> snianu: maybe one issue with checking active document. In chromium, browser process shows a dialog. When you click OK the promise resolves.<br>
&lt;Travis> .. between the time the OK is clicked, then the promise resolves, and inbetween that time the document loses focus. If the check for an active document occurs during that time, there could be a race.<br>
&lt;Travis> .. might be a chromium-specific case.<br>
&lt;Travis> BoCupp: for our permission dialog, I think we could ensure the scenario works.<br>
&lt;Travis> .. if it was other dialogs (unbounded) that might be a problem, but might be an edge case.<br>
&lt;Travis> github: https://github.com/w3c/clipboard-apis/issues/161<br>
&lt;Travis> BoCupp: I think we can make it work for this case.<br>
</details>


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