[w3c/clipboard-apis] Read Blob data for the supported formats on-demand during getType. (Issue #191)

Reading *all* supported formats from the clipboard during read() takes time especially since the HTML/Image payload can be in MBs/GBs. We could defer reading of the actual data from the clipboard and populate the clipboard item object with just promises to the blob data for all supported formats. That way we can resolve the promise with the actual data from the clipboard when getType is called. But this also means that we would have to track changes to the system clipboard as any change to the formats that was read during ClipboardItem object creation, would make the object stale/invalid. It also impacts formats that were delay rendered.

In the spec[1] it explicitly states that [read](https://w3c.github.io/clipboard-apis/#dom-clipboard-read) should read all the data from the system clipboard in step 3. When [getType](https://w3c.github.io/clipboard-apis/#dom-clipboarditem-gettype) is called, we resolve the promise to the data that was read during Clipboarditem object creation in step 6.

Should we make a change to the spec to read the data on-demand and not upfront? This would also help in delayed rendering of formats.

Note that in Chromium, DataTransfer APIs already follow a similar pattern where the sequence number is checked to see if the clipboard data that was read during the data transfer item object creation is stale or not: https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/clipboard/data_object_item.cc;drc=4c2fec5f6699ffeefd93137d2bf8c03504c6664c;l=215

@inexorabletash @evanstade @annevk @whsieh @sanketj

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

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