Re: [clipboard] Semi-Trusted Events Alternative

> 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?


That may be true in the modern browsers that compliant with the Editing
spec[1] but it certainly won't work for trying to detect the need for Flash
fallbacks in older browsers as some of them will throw an Error instead of
returning false.

An old-school-compliant example is much more verbose, e.g. [2], and may
additionally require that the document is in designMode or that the
contents/target are contentEditable.


[1]:  https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html#execcommand()
[2]:  https://gist.github.com/JamesMGreene/b709c2c57192ea39eb6b

Sincerely,
    James Greene


On Sat, Sep 13, 2014 at 3:58 PM, Hallvord R. M. Steen <hsteen@mozilla.com>
wrote:

> 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
>