Re: [w3c/clipboard-apis] Defer OS clipboard read from clipboard.read() to ClipboardItem.getType() (PR #248)

@EdgarChen commented on this pull request.



> @@ -918,6 +928,46 @@ url: https://storage.spec.whatwg.org/#obtain-a-storage-key-for-non-storage-purpo
 
     1. If |representation|'s [=representation/MIME type=] is |mimeType| and |representation|'s [=representation/isCustom=] is |isCustom|, then:
 
+     1. If [=this=]'s [=ClipboardItem/clipboard change count at read=] is not null, and the current [=clipboard change count=] is not equal to [=this=]'s [=ClipboardItem/clipboard change count at read=], then [=reject=] |p| with a {{"DataError"}} {{DOMException}} in |realm|, and return |p|.
+
+      Note: This ensures that stale data is never returned. If the [=system clipboard=] contents have changed since {{Clipboard/read()}} was called, this MUST fail rather than returning data that does not correspond to the current [=system clipboard=] state.
+
+      Note: A null [=ClipboardItem/clipboard change count at read=] indicates that this {{ClipboardItem}} was constructed directly by the author (e.g., via {{ClipboardItem/ClipboardItem(items, options)}}), not obtained from {{Clipboard/read()}}. In that case, no stale-data check is needed because the data does not originate from the [=system clipboard=].
+
+     1. If |representation|'s [=representation/data=] is not yet resolved, run the following steps [=in parallel=]:

We check whether the `representation`'s `data` (which is [promise](https://www.w3.org/TR/clipboard-apis/#representation-data)) is already resolved. What if two `getType()` called twice in a row with the same MIME type? Would it be possible both `getType()` calls to try to resolve or reject the data promise?
Maybe we need some way to handle that case?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/clipboard-apis/pull/248#pullrequestreview-4318205694
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/clipboard-apis/pull/248/review/4318205694@github.com>

Received on Tuesday, 19 May 2026 10:49:05 UTC