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

I’m working on an application that works with potentially huge SVGs that
get lazily optimized with svgo before being put on the clipboard (or being
saved to a file). So far I have worked with an ugly but functional solution
you can see in
https://bugs.webkit.org/show_bug.cgi?id=222262#c5. I haven’t run into it
yet, but in the worst case my svgo optimization task takes longer enough
for the user gesture to be expired. Not sure if this is a use case you were
looking for, but thought I’d share it.

Cheers,
Tom

On Mon 1. Nov 2021 at 12:43 mbrodesser ***@***.***> wrote:

> Thanks for raising those questions. Very important.
>
> ClipboardItem has ClipboardItemDataType which is a Promise to Blob or
> DOMString. When web authors don't resolve these promises in a reasonable
> amount of time, what should the Browser do in that case?
>
> It seems reasonable to consider relevant use cases to determine how
> browsers should behave in that case. Perhaps it's reasonable to assume that
> web-devs either
>
>    1. write small amounts of data to the clipboard, so that they can
>    resolve those promises in "a reasonable amount of time". A few seconds
>    seems reasonable.
>    2. write large amounts of data to the clipboard, which they can
>    prepare before calling clipboard.write.
>
> However, I don't know if 2) is true in practice. @AshleyScirra
> <https://github.com/AshleyScirra>: since you seem to be a web-dev, if you
> could contribute relevant use cases, that'd be helpful.
>
> Also, what happens if the promises to Blobs are resolved after the Browser
> Window loses focus?
>
> Interesting question. One reason to use the async clipboard API is that it
> doesn't block (mentioned e.g. at
> https://www.tiny.cloud/blog/new-async-clipboard-api/). So that could
> mean, a use case for end users could be to trigger a write(), but knowing
> that it may take time, switch to another application. So for that use-case
> it would be annoying to cancel the write().
>
> or user switches to another tab (while the promises are still not resolved
> in the first tab), opens the same site and starts another copy? Should we
> add a check to verify if the Document is active or not after the promises
> are resolved and before we write the payload to the clipboard? @whsieh
> <https://github.com/whsieh> @mbrodesser <https://github.com/mbrodesser>
> @BoCupp-Microsoft <https://github.com/BoCupp-Microsoft> @mkruisselbrink
> <https://github.com/mkruisselbrink>
>
> Perhaps it's reasonable to start with a short timeout, e.g. a few seconds,
> and not checking if the document is active. If, in practice it turns out to
> be an issue, one could still consider more subtle behavior and
> specification.
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
> <https://github.com/w3c/clipboard-apis/issues/161#issuecomment-956163499>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AABDSDFG4KFBD4LWMDKNEYLUJZ4NLANCNFSM5G26TKKQ>
> .
> Triage notifications on the go with GitHub Mobile for iOS
> <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
> or Android
> <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
>
>
-- 
Thomas Steiner, PhD—Developer Advocate (https://blog.tomayac.com,

https://twitter.com/tomayac)

Google Germany GmbH, ABC-Str. 19, 20354 Hamburg, Germany
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
Registergericht und -nummer: Hamburg, HRB 86891

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.3.2 (GNU/Linux)

iFy0uwAntT0bE3xtRa5AfeCheCkthAtTh3reSabiGbl0ck0fjumBl3DCharaCTersAttH3b0ttom.
hTtPs://xKcd.cOm/1181/

-----END PGP SIGNATURE-----


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