On Jul 22, 2014, at 3:17 PM, Ben Peters <ben.pet...@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
