Should reading the clipboard throw DataError or empty clipboard items?

[snianu]

https://w3c.github.io/clipboard-apis/#dom-clipboard-read suggests that reading the clipboard and not returning any items (such as when only unsupported types are on the clipboard) should return an empty list. In Chrome, we throw a DataError. Should we return an empty clipboardItem (to match the spec) or change the spec to throw DataError?
@annevk @mbrodesser @BoCupp-Microsoft @whsieh

[css-meeting-bot]

The Web Editing Working Group just discussed should reading the clipboard throw DataError or empty clipboard items?.

The full IRC log of that discussion

<Travis> topic: should reading the clipboard throw DataError or empty clipboard items?
<Travis> github: https://github.com//issues/179
<Travis> (reads the issue)
<Travis> whsieh_: this is the situation where there IS data on the clipboard, but none of it can be consumed by the webpage...?
<Travis> .. seems weird to throw a DataError in the case where there is nothing in the clipboard/pasteboard...
<Travis> .. in that case, returning an empty list.
<Travis> travis: I like just returning an empty list too--easy for web authors to handle with erroring out...
<Travis> whsieh_: In the specific example that snianu (Anupam) gave, I'm not sure if the error is OK.
<Travis> .. probably can't resolve on this at this time without further discussion with snianu?
<Travis> s/snianu?/snianu.
<Travis> johanneswilm: can the JS Editors differentiate between the different error conditions?
<Travis> .. could the user re-request? E.g., if the user didn't grant permission?
<Travis> whsieh_: recap; there are cases where a website might want to know whether they can try again, or whether they shouldn't try again.
<Travis> .. empty list vs throw error could be a way to differentiate.
<Travis> johanneswilm: there are two other cases...
<Travis> .. one where the user didn't give access, and one where the clipboard is changed after access is granted.
<Travis> whsieh_: in the first case, Safari throws "NotAllowed" (from the user denying paste).
<Travis> .. in the case where it changed, we also throw an error; but the type of error may not make sense...
<Travis> .. could look at changing it?
<Travis> (no resolution yet)

[EdgarChen]

In Gecko, we don't throw error, either, though we have a bug where we return a clipboard item with empty types currently, https://bugzilla.mozilla.org/show_bug.cgi?id=1756955.

[css-meeting-bot]

The Web Editing Working Group just discussed Should reading clipboard throw or return empty?.

The full IRC log of that discussion

<Travis> Topic: Should reading clipboard throw or return empty?
<Travis> github: https://github.com//issues/179
<Travis> snianu: Seems like a similar issue to 180.
<Travis> .. if there's no HTML format in the clipboard, and the author tries to read HTML format, then what?
<Travis> .. makes sense to throw a DataError.
<Travis> .. even though the clipboard has some data, just not what is desired.
<Travis> snianu: If authors are trying to read HTML, but the clipboard has something that's not in the supported types.
<Travis> .. the clipboard item won't have any data.
<Travis> whsieh: interesting to note: clipboard being empty is a valid system state.
<Travis> .. ex: calling clear contents from the OS. The technical truth is that there are no items in the clipboard.
<Travis> .. how would authors use this knowledge?
<Travis> .. (trying to come up with a scenario)
<Travis> .. I guess it makes sense (either way we go) to have some consistency.
<Travis> snianu: Currently we throw DataError in Chromium. So does Firefox.
<Travis> whsieh: Pretty sure Webkit will return an empty array of items.
<Travis> .. I think we can adjust our behavior to match; a DataError seems pretty sensible.

[annevk]

Throwing seems a little weird to me when there is no data to return. If there truly is no data an empty sequence seems good. And if there is an item but its types cannot be read I could somewhat see wanting to filter such items out, but that might also make it harder to provide decent UI indicating to the user what might have gone wrong. So I'd prolly return the item with no exposed types for that case.

[snianu]

@evanstade FYI..

[snianu]

RESOLUTION: Keep the exception during write(), but return empty ClipboardItem during read() if system clipboard is empty.
Full discussion:
[17:25] next up: #198
[17:26] trying to speak
[17:26] can you hear me?
[17:26] snianu: audio issues, let's move on for now
[17:26] snianu: nvm audio issues fixed!
[17:27] snianu: if clipboard item is empty and developer writes to clipboard, the write will throw an exception in Chrome but FF/WebKit allows that
[17:28] s/clipboard item is empty/clipboard item list is empty/
[17:28] snianu: creates confusion for web dev since it's unclear if they need to retry, or…
[17:28] q+
[17:29] q+
[17:29] s/developer writes to clipboard/developer reads from clipboard/
[17:29] q-
[17:29] snianu: read should not throw exception, write should throw exception
[17:30] snianu: with current DT APIs dev cannot clear clipboard by writing
[17:30] snianu: with async clipboard API you can write empty item (?)
[17:30] snianu: maybe flag to indicate that clipboard item is intentionally "empty"
[17:30] q+
[17:32] whsieh: if we want to expose a "clear clipboard" API, it should probably be navigator.clipboard.clear() or something
[17:33] johanneswilm: seems we're all in agreement
[17:33] sanketj_: to summarize, allow read empty items