- From: Hallvord R. M. Steen <hsteen@mozilla.com>
- Date: Sat, 13 Sep 2014 13:58:07 -0700 (PDT)
- To: Ben Peters <Ben.Peters@microsoft.com>, "James M. Greene" <james.m.greene@gmail.com>
- Cc: Perry Smith <pedzsan@gmail.com>, public-webapps@w3.org
After some further tweaking, I think the spec has found a pretty good balance between security and usability - even for paste.
* copy/cut: we allow writing to the clipboard when copy/cut events are triggered from trusted UI, and when document.execCommand('copy') and document.execCommand('cut') are called from any JS thread that would be allowed to open a popup (i.e. generally in response to user interaction)
* paste: we allow reading clipboard contents if the paste event is not synthetic and not triggered from a document.execCommand('paste') call. There's also an exception that will allow scripts to read the clipboard data in contexts where the UA is configured to allow this (could be for example white-listed, trusted sites or apps).
The reasoning is that if a "paste" event is neither synthetic (via dispatchEvent()) nor triggered from document.execCommand(), it's triggered from the browser's trusted UI (Edit menu/right-click menu/ctrl-v) and thus pretty reliably expresses the user's intention to let the web site read clipboard data.
The processing model should now handle all of that correctly. The descriptive prose could perhaps be improved to describe how it's meant to work.
Also, on the topic of discoverability I note that document.execCommand() is supposed to return true or false, depending on whether the command was enabled and successful or not. Might that be sufficient for discoverability? So if, in response to a click event your document.execCommand('copy') call returns false, you will have to fall back on the Flash clipboard widgets. Might be all you need?
-Hallvord
Received on Saturday, 13 September 2014 20:58:34 UTC