Re: [w3c/clipboard-apis] [Async Clipboard API] Use Stream APIs to provide data during write (Issue #212)

> If most of the use cases for delayed write includes a time-consuming computation, it would be best for them to use stream to not block the main thread

Even for formats that are not delayed rendered, this would be a useful addition to the async clipboard API. It would be nice not to force web authors to use delayed clipboard rendering if they want to take advantage of this memory optimization for read/write.

> (It could also be a mitigation for privacy problem for custom formats if the stream consumption immediately starts but with artificial intervals, so that the triggering page have a hard time detecting when the actual paste happens with which format.)

Like it was mentioned in [this ](https://github.com/w3c/editing/issues/439#issuecomment-1834546159)comment, this defeats the purpose of delay rendering the expensive formats as the web authors are forced to trigger the callbacks. We [resolved ](https://github.com/w3c/editing/issues/439#issuecomment-1934719705)the privacy issue to only support delayed rendering for built-in formats for now, but we will explore options to extend this support to web custom formats with the privacy mitigation in-place in the future.

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

Message ID: <w3c/clipboard-apis/issues/212/1936646160@github.com>