Re: [clipboard] Semi-Trusted Events Alternative

On Jul 22, 2014, at 3:17 PM, Ben Peters <Ben.Peters@microsoft.com> wrote:

> Semi-trusted events in the Clipboard API spec [1] are a potential solution to an important problem- sites should be able to use the same infrastructure (clipboard events) with their own triggers (button with execCommand(‘paste’) as browser initiated clipboard operations (like user presses control+v or uses the context menu’s ‘paste’ option). However, I don’t really know if ‘semi-trusted’ events are the solution. Users will almost certainly be using the keyboard or mouse with websites, so requiring an event to originate from keyboard or mouse doesn’t seem to make them trusted at all. I know there has been some discussion of removing them from the spec [2].

I agree.  Users are going to click on somewhere in the page while browsing.  I don’t see how, selecting a line of text, clicking on a hyperlink, or pressing the down arrow key to scroll etc… could lead to indicate the user’s intention to expose the clipboard/pasteboard’s content to the web page.  I, as an user, certainly wouldn’t expect that to happen.

> As an alternative to semi-trusted events, perhaps we should have something similar to input type=”file”? Perhaps a new input type that must display a localized word for “cut”, “copy”, or “paste”, and must not be occluded by any other element, could trigger real, trusted clipboard events? I’m not sure how this would work, but it seems worth a discussion at least.

I think the challenge here is that the input=file brings up a dialog to choose a file whereas copy/paste doesn’t typically show such an UI and guaranteeing that the element isn’t occluded is that easy to determine for user agents.  On the other hand, if we added a new element that’s guaranteed to be displayed on top of all other elements (e.g. like a dialog element) then that might work.

- R. Niwa