add navigator clipboard, ClipboardItem #18
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This implements
navigator.clipboard.write
andnavigator.clipboard.read
, which both work withClipboardItem
s. It also adds a re-implementation ofClipboardItem
which supports Promises, adhering to the spec.write
, per the spec takes an array ofClipboardItem
s and writes to the clipboard. We're limited in what we can do here, so we extract thetext/plain
content of the first one and callwriteText
. This is a pretty reasonable default behaviour.read
, per the spec should return an array ofClipboardItem
s representing the user's current clipboard. We're limited what we can do here, so we callreadText
and convert it into aClipboardItem
with justtext/plain
.ClipboardItem
has apresentationStyle
attribute (defaulting to'unspecified'
unless it's passed as an option), andgetType()
always returnsBlob
s. In Chrome's buggy implementation,getType('text/plain')
will return a String. We've accounted for both possibilities innavigator.clipboard.write
just in case the polyfill isn't applied (e.g. Chrome adds promises but keeps their buggygetType()
behaviour).This means
await navigator.clipboard.write(await navigator.clipboard.read())
should be a no-op (as long as the user only has plain-text data in their clipboard) which feels like a sensible thing to do.Customer Support Data
Here are some tables representing the % of browsers we see that support (or don't support) these APIs.
Clipboard Write
(Note: "Other" browsers make up 0.408%)