1272296 - Permission and implementation for scripted paste (document.execCommand('paste') and permissions.request('clipboard'))

Status: RESOLVED DUPLICATE of bug 1578321

(Core :: DOM: Core & HTML, defect, P5)

Description

[Hallvord R. M. Steen [:hallvors]]

This bug is about implementing the core parts of the functionality described here:
https://public.etherpad-mozilla.org/p/hsteen-pastespec - pasted below in its current version:

An attempted mini-spec for document.execCommand('paste'), based on discussions and consensus in this thread on dev-platform-ux:
https://groups.google.com/forum/#!topic/mozilla.dev.platform.ux/KOMwsmIh-Go

We will enable webpages to trigger a clipboard paste from JavaScript if granted permissions by the user.
This will initially be implemented using the legacy document.execCommand('paste') call, but drafts of an improved model reading the clipboard asyncronously are also being written. We'll make sure the new model is well integrated with the legacy stuff and can co-exist.

High-level view: 
    * A document.execCommand('paste') call in a context where the 'clipboard' permission is granted will trigger a paste action as defined in the Clipboard API spec (W3C).
    * The paste action & event must trigger whether the cursor is in an editable context or not. If there is no cursor/selection in an editable element, the paste event must fire and scripts listening to it must get access to clipboard data - but nothing will actually be pasted since there is no editable element to paste into.
    * If the permission is not already granted, execCommand('paste') will simply fail and return false. Note that execCommand('paste') by itself will *not* trigger any permissions requests.
    * The scripted paste feature is discoverable by querying the "clipboard" permission. If this does not cause an error, the script can assume that scripted paste is supported.
    * To prevent abuse, we'll experiment with UI that signals to the user when the permission is granted *and used*. Every call to execCommand('paste') must trigger an indication in the UI that something happened, whereby the user can be reminded of this permission and easily revoke it if it's not wanted anymore.


To implement this, we need some work in core and some UI (there is of course also spec work that needs to happen).

1) Adding the "clipboard" permission

  * Permission is requested with navigator.permissions.request({name:'clipboard'})  (navigator.permissions landed in Fx45)
  * navigator.permissions.query/request({name: 'clipboard'}) will only be allowed from user-initiated threads and only if the page the thread is running within a page delivered over https:
    * We have a policy of enabling new security/privacy-sensitive features only on secure pages
  * first promise callback should be considered user-initiated if the thread that created the promise was (enabling the desirable permissions.request({name:'clipboard'}).then(()=>(document.execCommand('paste'))) coding pattern.) (Note: this may require a follow-up bug, I don't know how user-initiatedness and promises work at the moment)

2) UI

  * The permissions query creates a "doorhanger"-type sign, icon is scissor or something else recognisable to do with cut-and-paste

  * Warning text: "Firefox has prevented this site from gaining access to your clipboard. Do you want to let this page read data from your clipboard?". Buttons "Don't allow", "Allow", we should also have some "Remember decision" UI

    * Alternative: “Allow [url_value] to access what you have cut and copied on this computer? [Allow Now] [Allow and Remember]”

    * Mockup: http://f.cl.ly/items/0I2u2q3e0S3H3d052t3a/allow-paste.PNG

    * -- please consult Aislinn Grigas regarding permissions UX (I believe that she might be on maternity leave for a little while longer)

  * If the permission is granted "Always", a small icon representing the clipboard access appears in the address bar. Every time the page does exeCommand('paste'), this icon will animate - one single "pulse" per paste is best - indicates that one "event" happened and hopefully strikes a balance between signalling that "something" happened and not beeing too distractive.

    * Alternative: same behaviour, minus the blinking

  * If you click this icon, it brings up a dialog that
    * Explains the scripted paste feature in simple terms ('You have allowed this page to see everything that you cut and copy on this computer.')

    * Alternative text: “[url_value] is allowed to access what you have cut and copied on this computer: [Block] [Continue Allowing]”

    * Mockup: http://f.cl.ly/items/3V1J0j3n2v3l1T1X3R2t/block-paste.PNG

    * Shows a snippet of the last text the page read in a scripted paste (or some alternative text if the last paste was data) explaining that the page already read this?

    * Offers a simple way to revoke the permission

3) Other precautions

  * Neither permissions.query({name:'clipboard'}) nor execCommand('paste') can be called outside user-triggered threads. (A possible exception for addon code though..)

Comment 1

[Adam Roach [:abr]]

Richard, Steve -- want to make sure this is on your radar.

Comment 2

[Andrew Overholt [:overholt]]

(In reply to Hallvord R. M. Steen [:hallvors] from comment #0)
> 1) Adding the "clipboard" permission
> 
>   * Permission is requested with
> navigator.permissions.request({name:'clipboard'})  (navigator.permissions
> landed in Fx45)

Supporting Permissions.request is bug 1193376.

I heard that Ehsan may not like the idea of a clipboard permission; I'll let him elaborate when he has time.

Comment 3

[(no longer active)]

(In reply to Andrew Overholt [:overholt] from comment #2)
> (In reply to Hallvord R. M. Steen [:hallvors] from comment #0)
> > 1) Adding the "clipboard" permission
> > 
> >   * Permission is requested with
> > navigator.permissions.request({name:'clipboard'})  (navigator.permissions
> > landed in Fx45)
> 
> Supporting Permissions.request is bug 1193376.
> 
> I heard that Ehsan may not like the idea of a clipboard permission; I'll let
> him elaborate when he has time.

Comment 0 only lists some alternatives.  I'm not sure which one we're going to implement, but my worries are around communicating the concept of the clipboard to the user.  I'm perfectly happy to leave that to the UX team.

As far as the permission issue goes, I'm not crazy about that idea but it's quite clear at this point that nobody else has any better proposals, so we should probably use a permission.

Comment 5

[Anne (:annevk)]

Let's dupe this into bug 1578321.