Support for putting images on the clipboard about clipboard-apis HOT 9 OPEN

The reason that I don't trust sanitizing images is that we render out up to 32k x 32k PNG and JPG. We also pass-through APNG files, and would like to pass through GIF. I can see the sanitizer trying to open these large files to re-render them and failing, or the alternative is doing all the work on the CPU and taking forever for large images. These files are all small enough once compressed but can still be a few hundred MB, and it feels like all attack vectors are in the header or IDAT lengths in the case of PNG.

from clipboard-apis.

It would definitely mitigate the security concern if the browser is the one encoding the image.

from clipboard-apis.

The current specified API lacks the ability to put images on the clipboard.

The intent of the recently-added Async clipboard API is that it supports image data. The old synchronous clipboard API is not going to support image copy, primarily because of security concerns that can only be addressed with an async API.

See the recent async clipboard proposal for background on this. In summary, for image support the clipboard API needs to be async to allow (1) the image data to be santiized, and (2) to allow user agents to query the user for permission.

Also, in general, execCommand() in somewhat deprecated in that it is not going to be updated and no new specs will be written to rely on it.

We discussed adding helper accessors to read/write "text" and "image" data from/to the clipboard, but so far I've only added the "text" helpers in the spec. Adding image helpers would make it more apparent that the API is intended for images as well, so I should go ahead and do that (and add examples).

This is intended to be a temporary solution until we can agree on a common implementation to be shared between browsers.

The current async proposal is the result of the browser vendors discussing and coming to an agreement on how we should address this.

So, rather than adding a browser-specific temporary solution, you should consider adding support for the async API instead. Since there is already cross-browser agreement for this (and Chrome is currently working on an implementation that will ship soon), it will probably be a lot easier to get approval for your changes.

Let me know if you have any questions -- especially if you start working on an implementation since the first two independent implementations are always the most critical.

from clipboard-apis.

The intent of the recently-added Async clipboard API is that it supports image data.

Please formalize this intent in the draft spec. Write-access to common image types seems to be left out whereas read-only access seems possible.

If the spec'd API is stable, I can look into getting it implemented in Firefox. There are already some open bugs with no assignee:

• https://bugzilla.mozilla.org/show_bug.cgi?id=1351193 Implement the DataTransfer constructor
• https://bugzilla.mozilla.org/show_bug.cgi?id=1221562 Investigate asynchronous DataTransfer API

In the last bug, there is feedback on the API, but I guess that it never got to you since there is no reply: https://bugzilla.mozilla.org/show_bug.cgi?id=1221562#c4. Perhaps you can take a look at it?

And for image copying, I created an experimental prototype to see what issues would arise in implementing the functionality (independent of how the API looks like). The results are summarized in my initial report here, so please review those bullet points too.,

from clipboard-apis.

In the last bug, there is feedback on the API, but I guess that it never got to you since there is no reply: https://bugzilla.mozilla.org/show_bug.cgi?id=1221562#c4. Perhaps you can take a look at it?

Yes, there is general agreement that DataTransfer should also get an async API. When (if?) that happens, the async Clipboard API implementations would be trivially updated to use it.

But we don't want the async Clipboard API to be blocked on resolving Drag-n-drop issues (which would certainly be brought up in the context of revisiting DataTransfer).

I believe the plan (although I don't know of anyone actively working on it) is to have an async Drag-n-drop proposal and use that to motivate changes to DataTransfer. I agree that it would have been nice if DataTransfer already had an async Promise-base API, but that's not likely to happen anytime soon.

And for image copying, I created an experimental prototype to see what issues would arise in implementing the functionality (independent of how the API looks like). The results are summarized in my initial report here, so please review those bullet points too.,

Will do. I'm working on Chrome's implementation, so I've bumped into some of them, but I hadn't considered others (like animated images). Thanks for summarizing.

When I've updated the spec with more info on image support, I'll update this issue so that you can take a look at the changes and make comments.

from clipboard-apis.

As far as I can tell, the primary problem we have is that we don't have a mechanism to asynchronously add image data to DataTransferItemList. If we added such a method, we can support putting images into pasteboard/clipboard without having to add navigator.clipboard at least in WebKit since we can sanitize images inside those methods instead of sanitizing the entire DataTransfer object at once.

from clipboard-apis.

@rniwa

Would the need for sanitizing the image disappear if the image data is sourced from the browser instead of directly set by the user?
For instance, if the add method of DataTransferItemList were to accept views of images, e.g. HTMLImageElement, HTMLCanvasElement, CanvasRenderingContext2D, or (independent of documents, usable in workers too:) ImageBitMap, then web authors can set an image, and browsers have full control over what ends up on the clipboard.

from clipboard-apis.

Can you please use the original image if it doesn't need sanitizing, rather than using the re-encoded image. Our application needs to get the original user images with metadata out to other design tools.

from clipboard-apis.

Proposal: https://docs.google.com/document/d/1sMcajoYAQ_M_VOIn1RLokG1sVB7skjoeviqt9aZOcDk/edit

from clipboard-apis.