clipboard-apis
clipboard-apis copied to clipboard
w3c
Make it possible to read image/svg+xml from the clipboard
I get the impression here https://w3c.github.io/clipboard-apis/#reading-from-clipboard that the clipboard format image/svg+xml should be available when reading a data transfer object in the paste event. But I cannot get this to work. I have verified on Windows that there is indeed an image/svg+xml format on the clipboard, but I cannot see any traces of this when inspecting the clipboardData object in Chrome 75.0.3770.100. Have I misunderstood how this is supposed to work or is it simply not implemented in Chrome?
document.addEventListener('paste', async function (event) { event.preventDefault(); console.log(event.clipboardData.types); let clipText = event.clipboardData.getData("image/svg+xml"); console.log(clipText); }
What’s the actual input you are trying to copy? That is, how is the svg embedded in the HTML document. Is it inline svg? And img tag? Or object?
It is an SVG image copied from another program to the clipboard. This should be the same xml as is in a .svg file. It works fine to paste into other programs (Word, InkSkape etc.), but writing a clipboard handler in the browser for this format does not seem to be possible. The image format is not listed by the clipboardData element. From the specification, it is my impression that this is how it is supposed to work. The format is listed on https://w3c.github.io/clipboard-apis/#reading-from-clipboard, I cannot find any traces of it in Chromium here https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/clipboard/clipboard_mime_types.cc?sq=package:chromium&g=0
Interesting! And it doesn’t work in any browser? I wonder if svg is excluded because it can contain scripts?
I have tested only on IE, Edge and Chrome. Don't know if it makes sense to exclude this because of scripts. It is just XML and it depends on what you do with the content. With that reasoning, text on the clipboard can also contain scripts. Adaption of SVG is quite slow, which is a pity. I guess it is because it is not supported well in many tools. It looks like Office can paste SVG in the latest version, but popular apps like Adobe Illustrator and InDesign requires a plug-in to paste SVG (unless it has changed recently). I have not seen any web pages where you can paste SVG, which I suspect is because of the reason I posted here.
It seems reasonable to allow SVG. We strip away all scripts & event handlers from HTML anyway so we'd do the same here for SVG if any.
The primary concern with SVG is with how to sanitize it. If stripping out the scripts is acceptable from both the user and security perspective, then that sgtm.
@garykac : FWIW, WebKit strips away all scripts and event handlers for any cross-origin & cross-app copy & paste for HTML, and don't expose any raw RTF / RTFD content. See our blog post for the details.
In general, whenever we leave scripts or event handlers in the pasted HTML, we end up getting security bugs somewhere in our engine or XSS bugs on some websites so it's simply not unattainable to leave them in the pasted content. Furthermore, some native applications tend to put privacy & security sensitive information like the full physical address of the user and the path to app's privacy container in the system into the contents in the system pasteboard / clipboard, so some kind of sanitization step to remove any content that's not directly visible to the user is necessary from privacy perspective as well.
It sounds like a great idea to have the same sanitation of clipboard formats like HTML that webkit has. It would be nice to have this in Chromium and also for SVG.
It's also impossible to write image/svg+xml to the clipboard. It always throws a SecurityError that the MIME type is no allowed, which is really unfortunate.
it seems to no longer throw an error for image/svg+xml but when testing it did not let me paste it into powerpoint or the finder (while it works fine with a png)
I tested via this code
setTimeout(async () => {
try {
const imgURL = 'test.svg'; // using test.png works
const data = await fetch(imgURL);
const blob = await data.blob();
await navigator.clipboard.write([
new ClipboardItem({
[blob.type]: blob
})
]);
console.log('Image copied.');
} catch(e) {
console.error(e, e.message);
}
}, 1000);
is that supposed to work?
tested in chrome 95
Followed up with the @daKmoR via Twitter DM. Here's my response:
Copying SVGs works. See my demo at https://async-clipboard-demo.glitch.me and check the console. See how the SVG is there, alongside the PNG and plain text source code of the SVG? The problem is more the receiving app. It takes whatever works, and how it does that is an implementation detail. You can try flipping the order and put the SVG first, so if the receiving app can work with SVGs and uses whatever works first, then you might get lucky.
I tested it now in sketch, teams desktop app, twitter web, slack web app... as soon as you add the image/svg+xml it will "freak" out and try to paste the big svg text and freeze for a few seconds...
svgomg indeed works fine as it will use the text and is ready for bigger texts.
if you only use image/svg+xml in the clipboard nothing happens when you past it (tested the same apps as before). svgomg will also throw an error "pasted value not an svg"... I assume because as it expects a string and not an actual svg
so far I could not find a single app that could handle image/svg+xml... 😅
Does anyone know of a good example?
I tested my demo again that I also blogged about a while ago, and it still works, albeit only with the chrome://flags/#enable-experimental-web-platform-features set.
Let me ask internally where we are with shipping this—apparently—ready to go implementation.
Let me ask internally where we are with shipping this—apparently—ready to go implementation.
That's great!
There is one issue that needs further discussion before shipping: https://bugs.chromium.org/p/chromium/issues/detail?id=1226150
I don't think it's too much of a problem even if the sanitization process deletes the styles in the <style> tags, because many apps don't support <style>, e.g. <style> is lost when you paste it into Keynote 13.1 for editing.
There are two solutions:
- the developer converts the styles in style to SVG attributes.
- for 1, let the browser automate the process.
This results in better compatibility with SVG copied to the clipboard.
- See my comment on the bug for a possible third option.
Yeah, I made the same request here https://github.com/w3c/clipboard-apis/pull/197#issuecomment-1786694922.
@yisibl Would you be able to provide more details on your scenario for this API?
It is not clear to me which format name should be used for SVG on each platform in https://w3c.github.io/clipboard-apis/#to-os-specific-well-known-format and https://w3c.github.io/clipboard-apis/#to-well-known-mime-type-from-os-specific-format. It would be beneficial if we could also define that.
@EdgarChen Looks like we missed adding the SVG image mime type in those algorithms. I can make a change to add the OS formats and the SVG MIME type.
