Selective Clipboard Format Read

[shwetabin]

Hi,
I'd like to propose an addition to the Clipboard API - a way to efficiently get specific MIME types in the Async Clipboard Read API. The primary use case I have in mind involves web applications that support rich content editing, such as document editors, email clients, and data grids, which routinely deal with multiple types of clipboard payloads, including large HTML fragments, images, and custom MIME types. These applications often implement features like "Paste as plain text" or "Paste with formatting," where only a subset of the clipboard data is needed. You can find more detailed explainer at https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/ClipboardAPI/SelectiveClipboardFormatRead/explainer.md. Could we schedule a discussion at an upcoming meeting to figure out:

1. Is there consensus to address this problem?
2. If not, what extra data could help show that the use case is important?
3. If the use case does have consensus:
   1. Can we check the explainer into https://github.com/w3c/clipboard-apis?
   2. What concerns do people have about the proposed API shape?

[ashishkum-ms]

@annevk, thank you for your suggestion to consider adding new readTypes like api.
I think a separate readTypes API could offer some discoverability benefits (due to autocomplete in console when dev types navigator.clipboard.read..). But after reviewing, the benefits of extending the current read API with a types argument seem to
outweigh.
Extending the current read API with types argument:

1. Avoids introducing new overlapping API, since options like unsanitized data would need to be maintained across both APIs.
   This could mean maintaining two APIs that do pretty much same things. This may lead to increased maintenance overhead for user agents and the specification, particularly as new options are introduced in future.
   And that maintaining a single, API helps keep the platform simpler and more consistent for developers.

Looking forward to your further thoughts on this and open to feedback.

[EdgarChen]

(There are similar discussions in #191)

[annevk]

Thank you @EdgarChen for pointing that out! I learned something new there about Safari's implementation that I had not realized and was seemingly missed by all of us during the last meeting. That getType() is already lazy and needs to be called before the clipboard changes. And it's lazy in a way that I think works.

That is, if you do read(), followed by the user doing a fresh copy, followed by getType(), getType() will throw/return something empty.

That model seems vastly preferable over having to cache the entire clipboard item in memory/some side table store each time read() is called. Especially with the proposed clipboardchange event making it very clear at which point invalidation for a prior read() happens.

[ashishkum-ms]

@annevk, we believe making getType() lazy could introduce certain challenges:

1. According to the spec(as implemented in Chromium and Firefox), ClipboardItem represents a snapshot of the OS clipboard state at the time read() is called. If getType() is made lazy, it may break use cases where web apps rely on ClipboardItem as a cache of clipboard data—for example, storing separate ClipboardItem per checkpoint to maintain clipboard history.
2. While clipboarchange can help manage delays between read() and getType(), this would require web authors to handle additional complexity that might otherwise be avoidable.

We’re happy to discuss this further in today’s WG meeting if needed.

[annevk]

To handle that use case in Safari you'd have to eagerly fetch all the types you are interested in. I think that is a better model as only the websites that care about holding that much data in memory will end up paying for it.

Snapshotting the entire entry for each call to read() is really rather wasteful. As you've also realized per this issue. Since we have an opportunity to move away from it without any API change or opt-in from web developers (which as pointed out will likely not bother opting in unless they have large teams and the proper incentives), I think we should take it for the benefit of end users.

[johanneswilm]

TPAC 2025:

Rohan
I hope everyone is aware of this proposal to optimize MIME type reading
We want to optimize where the web author can request specific MIME types
We have two options, one was to specifically ask for a set of MIME types
The second option can cause certain backward compatibility challenges
This changes the behaviour of the clipboard item as well
With this change, this will give you the latest data every time it is called
We were concerned that some website were replying on the clipboard
To have a persistent state
Say a clipboard timeline application
So there was a backward compatibility list
To move forward we have added this in chromium
There are a few more concern around this
The backward compatibility issue
The user permission part
So if we are moving the read to the get type, do we want to move the
Permission to getType.
The other scenario is that you do the permission first.
Since the permission is refused.
Smaug
The permission model is where this is difficult
They were not expecting and error from getType
Rohan
If the clipboard changes between then it throws an error
But there are some backward compatibility issues that we want to see if there are actually issues here
Johannes
What are the backwards compatibility issues here
Smaug
If you give the permission once, then it has that access forever?
Rohan
Yes, but you can manually deny that permission in settings
So if the use denies the permission then it
Smaug
This seems a very unlikely scenario
Rohan
What if the clipboard never changes and the clipboard item and they might just what to read it later
Johannes
You are collecting telemetry data on this?
What exactly are you collecting
Rohan
We are, and checking to see if this permission changes
Johannes
This is only an issue if we have old clipboard items around
Rohan
This only matters if they have a cache
Johannes
They could read it later and that’s when there’s an issue later
If this is an issue, it’s only for Chromium
If the telemetry data shows that this isn’t really being done, so that would show that it’s not really an issue
Get back to us when we have the telemetry data?

[css-meeting-bot]

The Web Editing Working Group just discussed Selective clipboard format read.

The full IRC log of that discussion

<dandclark> topic: Selective clipboard format read
<dandclark> github: https://github.com//issues/240
<dandclark> Ashish: Last time we discussed adding telemetry
<whsieh> discussion: add telemetry
<whsieh> (oh, thanks for scribing dan!)
<dandclark> ...to see if we should move ahead with making getType() lazy
<dandclark> ...based on telemetry so far the instances where data chantged between calls is 1 in a million pageloads
<dandclark> ...so if we make getType lazy it could throw, or return empty string, if data is stale
<dandclark> ...throwing has higher compat risk for Chromium
<dandclark> ...would Safari be willing to make change to return empty change for stale data if Chromium changes getType to be lazy?
<dandclark> whsieh: instead of throwing ex, return empty string? Seems OK
<dandclark> ...willing to do that if we don't already
<dandclark> Ashish: And would FF be willing to change to this behavior?
<dandclark> ...if Chromium goes first
<dandclark> whsieh: Do we have anyone from FF on the call?
<dandclark> ...don't think so
<dandclark> dandclark: Ashish can you follow up with Olli in the thread?
<dandclark> Ashish: Yes
<dandclark> ...One more point regarding what to do if getType is called when document not in focus
<dandclark> ...currently we don't allow the read when not focused
<dandclark> ...But getType call succeeds when window is not in focused. Should we change this if getType is made lazy?
<dandclark> whsieh: As long as items have been read when document has focus
<dandclark> Ashish: But we're not reading data unless we have getType
<dandclark> whsieh: Focus restriction is only for getting items
<dandclark> ...even in background, can get data that was lazily delivered
<dandclark> whsieh: Might be compat issue if we started restricting getting type when document is in background
<dandclark> ...from WebKit perspective, probably safer to keep status quo, allow reading in background as long as items were obtained when you were active
<dandclark> dandclark: We should have WPTs
<dandclark> whsieh: Can you focus away from window in WPT
<dandclark> dandclark: I think you can have popup
<whsieh> https://github.com/w3c/input-events/issues/176
<dandclark> Rohan?: Or use iframe
<dandclark> johanneswilm: This has been mentioned before, we took up at TPAC
<dandclark> ...is the question of being able to isolate the composition
<dandclark> ...comments from Masayuki, some new data
<dandclark> ...Anyone from Mozilla want to discuss?
<dandclark> ...Masayuki implemented something not to spec to get around this problem
<dandclark> ...related to spec change he proposed in 2018
<dandclark> ...Let's wait until we have Mozilla people
<whsieh> https://github.com/w3c/input-events/issues/177
<dandclark> johanneswilm: Issue with WPTs that were introduced
<dandclark> ...Looks related to Chromium
<dandclark> ...Can we get someone to take a look?
<dandclark> dandclark: Rakesh could you follow up with Utkarsh re: https://un5x4n0kwa1t164zhzvdp2b4bu49r4r40ry9xdr.julianrbryant.com/c/chromium/src/+/5443103 ?
<dandclark> ...to answer questions on the github issue?

[EdgarChen]

...so if we make getType lazy it could throw, or return empty string, if data is stale
...throwing has higher compat risk for Chromium
...would Safari be willing to make change to return empty change for stale data if Chromium changes getType to be lazy?
whsieh: instead of throwing ex, return empty string? Seems OK
...willing to do that if we don't already
Ashish: And would FF be willing to change to this behavior?
...if Chromium goes first

Currently, getType() is not lazy in Firefox. However, we are willing to make it lazy and also return an empty string for stale data if the spec changes.

[roraja]

I've been thinking more about the lazy getType() approach (Option 2) and want to raise some concerns about what this does to ClipboardItem's semantics.

The core issue is that lazy getType() transforms ClipboardItem from a data object (snapshot of clipboard at read-time) to a service proxy (lazy fetcher that may fail if clipboard changed). This is a fundamental semantic shift which might confuse web developers.

Consider the current interface:

readonly attribute FrozenArray<DOMString> types;
Promise<Blob> getType(DOMString type);

The types property is a FrozenArray—explicitly immutable—which signals to developers: "these types are fixed and available." But with lazy getType(), this becomes misleading. A developer might see types includes "text/plain", call getType("text/plain"), and get an error/empty data because the clipboard changed. The FrozenArray implied availability that doesn't exist.

More fundamentally, the spec describes ClipboardItem as:

"conceptually data that the user has expressed a desire to make shareable by invoking a 'cut' or 'copy' command."

This is snapshot language—data from a past action. Lazy getType() changes this to: "a handle to whatever is currently on the clipboard, which may or may not match what was there when you called read()."

However, if a web developer creates a new ClipboardItem for writing purpose, then the semantic meaning again switches back to being a “fronzen data container”, further adding to the confusion for web developers and creating inconsistency in the interface.

// This now acts like a frozen data object, getType won't error out if clipboard changes
const item = new ClipboardItem({ "txt/plain": "My text", “txt/html”: “My html” })
navigator.clipboard.write(item)

So "ClipboardItem" now behaves both like a frozen data object when created explicitly by web author and also like a service proxy which fetches latest data or empty data if the clipboard changed after read() call. I think makes the API look not simple to understand and unintuitive as the web developer has to understand all these special cases under which the behavior changes.

Any thoughts ?