Re: [w3c/clipboard-apis] Selective Clipboard Format Read (Issue #240)

johanneswilm left a comment (w3c/clipboard-apis#240)

Call 2026-02-12:

> 08:36 <whsieh> rohan: second approach (engine reads lazily) is more favorable since all websites would get the benefit
08:36 <whsieh> rohan: however, I wanted to raise concern from API perspective
08:37 <whsieh> rohan: right now ClipboardItem ctor acts as "frozen bag of data"
08:37 <whsieh> rohan: however, once you do a read() you no longer get "frozen data", but a live reference to OS state
08:37 <whsieh> rohan: might create confusion for web devs
08:38 <whsieh> rohan: ...since clipboard items obtained via read behave differently than items created when writing
08:39 <whsieh> smaug: I think it still makes sense (the lazy item read() behavior)
08:39 <whsieh> smaug: it's kinda just how the clipboard works
08:39 <edgar> q+
08:40 <whsieh> Rakesh: seems like a fair tradeoff?
08:40 <whsieh> smaug: not really a tradeoff, just makes sense
08:40 <whsieh> edgar: there's also a proposal about the clipboard change event
08:40 <whsieh> edgar: we know the clipboard changed at a specific time, so developers who really need to handle this item change case can respond accordingly
08:42 <whsieh> rohan: the question is, should the browser invalidate the clipboard item when its content changes
08:43 <Rakesh> q+  want to take opinions on returning no data(failing silently) vs throwing exception
08:43 <whsieh> johanneswilm: is the concern with JS authors that keep items around
08:44 <whsieh> rohan: yes
08:44 <whsieh> smaug: I thought we'd be taking WK's current behavior?
08:44 <whsieh> (yes)
08:44 <Rakesh> yes
08:45 <whsieh> johanneswilm: WK has this behavior of invalidating already, so if there have not been issues with it then probably it's fine
08:45 <whsieh> Rakesh: wanted to discuss — returning no data(failing silently) vs throwing exception
08:46 <whsieh> Rakesh: would it help to fail silently?
08:46 <whsieh> johanneswilm: but this means they might not discover the bug
08:46 <whsieh> johanneswilm: (whereas with exception if someone were depending on it, they'd know)
08:47 <whsieh> smaug: the end user wouldn't want the stale data to persist in this case
08:48 <whsieh> Rakesh: how would developer distinguish between clipboard having *no* data vs. clipboard item being stale
08:48 <whsieh> smaug: clipboard change event
08:48 <whsieh> dandclark: can I write the empty string today?
08:48 <whsieh> shweta: it's actually valid to write empty string
08:49 <whsieh> dandclark: can't tell between actual empty string vs. empty string due to staleness
08:49 <whsieh> dandclark: rather they'd need to use clipboard change event to do sio
08:49 <whsieh> dandclark: so it seems better to throw here vs. fail silently
08:49 <whsieh> (to make distinction b/t the two cases)
08:50 <whsieh> whsieh: I think we throw rn
08:50 <whsieh> (in WK)
08:50 <whsieh> dandclark: would be good to double check behavior
08:51 <whsieh> shweta: the error in Safari currently doesn't say "clipboard changed", just a generic "not allowed"
08:51 <whsieh> dandclark: maybe this should be implement ion-defined?
08:52 <whsieh> whsieh: we could probably provide a more descriptive error in WK
08:53 <whsieh> johanneswilm: if JS is depending on it, then there's probably something wrong with their code anyways...
08:53 <whsieh> johanneswilm: would be more practical to explain what's wrong
08:54 <whsieh> dandclark: exception type should be consistent, the error detail can be more specific
08:54 <whsieh> johanneswilm: where would this be specified?
08:54 <whsieh> rohan: should be in getType()
08:55 <whsieh> johanneswilm: explanatory note would be helpful there
08:55 <whsieh> dandclark: I think we also need normative text for this
08:56 <whsieh> johanneswilm: so: (1) normative spec change, (2) explanatory note, (3) change in Chromium/Gecko to align

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

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

Received on Thursday, 12 March 2026 11:44:25 UTC