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

> @mbrodesser Thank you for your response! We are planning to discuss this in the Editing WG call on 11/12, but here are some thoughts:

Thanks for sharing them.

> 
> > I think end users need to be informed visually when a write*() call starts, as long as it hasn't finished and when it's indeed finished.
> 
> Yes, this is what we are planning to do in Office online products (at least Excel online for now). Since the payload is big, it takes an arbitrary amount of time to resolve the promises, so we are going to show a message or something if the user tries to move the focus away from the tab.
> 
> In general, I think setting any time limit would be problematic because you could always create something that would break it.
> 

True.

> > Two write operations should not be allowed to overlap. If there's indeed a time intensive write*() going on and an end user wants to start a different one, the first one should clearly be aborted.
> 
> Yes, I agree that there shouldn't be any overlap,

Just want to stress this is important. For end users' understanding and to keep the clipboard API simple.
If a `write*()` call immediately fails, when another `write*()` call is still running, no overlap would be possible.
Moreover, if only the active document would be allowed to `write*()`, one tab / iframe / website couldn't block other tabs from writing.

> but from Chromium's perspective, it's hard to tell which one to cancel as the write takes place in the browser process and there could be many renderer processes initiating the write call at different intervals (due to payload size etc).
> 
> One way to solve all these issues related to timing and stuff is to implement[ Delay Rendering](https://docs.microsoft.com/en-us/windows/win32/dataxchg/clipboard-operations#delayed-rendering) that gives authors the ability to serialize only the payload associated with the MIME type requested by the OS, but not sure when we are going to work on it (hopefully soon!).

IIUC, this wouldn't solve the timing problem. The payload associated with one MIME type could still be large.



-- 
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-965058792