Intent to implement and ship: document.execCommand("cut"/"copy")

[Ehsan Akhgari]

Summary: We currently disallow programmatic copying and cutting from JS for
Web content, which has relied on web sites to rely on Flash in order to
copy content to the clipboard. We are planning to relax this restriction
to allow this when execCommand is called in response to a user event. This
restriction mimics what we do for other APIs, such as FullScreen.

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1012662

Link to standard: This is unfortunately not specified very precisely.
There is a rough spec here: <
https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html#miscellaneous-commands>
and the handling of clipboard events is specified here: <
https://w3c.github.io/clipboard-apis/>. Sadly, the editing spec is not
actively edited. We will strive for cross browser interoperability, of
course.

Platform coverage: All platforms.

Target release: Firefox 40.

Preference behind which this will be implemented: This won't be hidden
behind a preference, as the code changes required are not big, and can be
easily reverted.

DevTools bug: N/A

Do other browser engines implement this: IE 10 and Chrome 43 both implement
this. Opera has adopted this from Blink as of version 29.

Security & Privacy Concerns: We have discussed this rather extensively
before: <http://bit.ly/1zynBg7>, and have decided that restricting these
functions to only work in response to user events is enough to prevent
abuse here. Note that we are not going to enable the "paste" command which
would give applications access to the contents of the clipboard.

Web designer / developer use-cases: This feature has been rather popular
among web sites. Sites such as Github currently use Flash in order to
allow people to copy text to the clipboard by clicking a button in their UI.

Cheers,
--
Ehsan

[Robert O'Callahan]

On Wed, May 6, 2015 at 9:51 AM, Ehsan Akhgari <ehsan....@gmail.com>
wrote:

> Summary: We currently disallow programmatic copying and cutting from JS for
> Web content, which has relied on web sites to rely on Flash in order to
> copy content to the clipboard. We are planning to relax this restriction
> to allow this when execCommand is called in response to a user event. This
> restriction mimics what we do for other APIs, such as FullScreen.
>

Sounds great!

Rob
--
oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
owohooo
osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
oioso
oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
owohooo
osoaoyoso,o o‘oYooouo ofooooolo!o’o owoiololo oboeo oiono odoaonogoeoro
ooofo
otohoeo ofoioroeo ooofo ohoeololo.

[Jet Villegas]

\o/ Great to see this come through. Shumway was already using this but
needed chrome privilege to do so. It's nice to open it up.

--Jet

On Tue, May 5, 2015 at 2:51 PM, Ehsan Akhgari <ehsan....@gmail.com>

wrote:

> Summary: We currently disallow programmatic copying and cutting from JS for
> Web content, which has relied on web sites to rely on Flash in order to
> copy content to the clipboard. We are planning to relax this restriction
> to allow this when execCommand is called in response to a user event. This
> restriction mimics what we do for other APIs, such as FullScreen.
>

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

[Daniel Holbert]

On 05/05/2015 02:51 PM, Ehsan Akhgari wrote:
> Sites such as Github currently use Flash in order to
> allow people to copy text to the clipboard by clicking a button in their UI.

Bugzilla does this, too! [1] (If you enable "experimental user
interface" in your account's General Preferences.)

Looking forward to not needing flash for this anymore!

~Daniel

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1149593#c1

[Ehsan Akhgari]

On 2015-05-05 6:31 PM, Daniel Holbert wrote:
> On 05/05/2015 02:51 PM, Ehsan Akhgari wrote:
>> Sites such as Github currently use Flash in order to
>> allow people to copy text to the clipboard by clicking a button in their UI.
>
> Bugzilla does this, too! [1] (If you enable "experimental user
> interface" in your account's General Preferences.)

Good point! Filed bug 1161797 for that.

[Tantek Çelik]

On Wed, May 6, 2015 at 12:51 AM, Ehsan Akhgari <ehsan....@gmail.com> wrote:
> On 2015-05-05 6:31 PM, Daniel Holbert wrote:
>>
>> On 05/05/2015 02:51 PM, Ehsan Akhgari wrote:
>>>
>>> Sites such as Github currently use Flash in order to
>>> allow people to copy text to the clipboard by clicking a button in their
>>> UI.

First, this is awesome and can't wait to try it out.

Second, "cut" is potentially destructive to user data, have you
considered enabling this only for secure connections? Either way it
would be good to know the reasoning behind your decision.

Tantek

[Ehsan Akhgari]

Hmm, what would that prevent against though? A web page could just use the
normal DOM APIs to destroy the user data (e.g., something like the contents
of a blog post the user is writing in a blogging web app). Is this what
you had in mind?

--
Ehsan

[Tantek Çelik]

Sorry I wasn't clear. *Both* "cut" and "copy" have the impact of
*clearing* the previous clipboard data (on typical platforms).

Thus if the user had say, cut a bunch of text from another application
(like a text editor), and then switched to a browser window, gotten
distracted and clicked something, it is *possible* the page could
select text, do a cut/copy, and blow away that bunch of text from the
other application.

Result: loss of user data that user had put into the clipboard
previously. This isn't possible with current DOM APIs and is a new
vulnerability introduced by cut/copy.

Tantek

[Gervase Markham]

On 06/05/15 08:00, Tantek Çelik wrote:
> Result: loss of user data that user had put into the clipboard
> previously. This isn't possible with current DOM APIs and is a new
> vulnerability introduced by cut/copy.

Given that most text-editing applications have "undo" (if you used "cut"
originally), this strikes me as a low-level web page annoyance on a par
with auto-playing irritating music. Although perhaps a little less
discoverable as to the cause. I doubt this will be an issue in practice
- as the page doesn't get to see the data its deleting, doing so would
be pure vandalism, not worthy of an attacker who was trying to actually
accomplish something.

Gerv

[Gervase Markham]

On 06/05/15 08:00, Tantek Çelik wrote:

> Result: loss of user data that user had put into the clipboard
> previously. This isn't possible with current DOM APIs and is a new
> vulnerability introduced by cut/copy.

[Tantek Çelik]

On Wed, May 6, 2015 at 10:51 AM, Gervase Markham <ge...@mozilla.org> wrote:
> On 06/05/15 08:00, Tantek Çelik wrote:
>> Result: loss of user data that user had put into the clipboard
>> previously. This isn't possible with current DOM APIs and is a new
>> vulnerability introduced by cut/copy.
>
> Given that most text-editing applications have "undo" (if you used "cut"
> originally),

^^^ desktop assumption.

Most (nearly all?) text editing applications and/or applications with
editable text fields on *mobile* DO NOT have "undo".

> this strikes me as a low-level web page annoyance on a par
> with auto-playing irritating music.

^^^ disagreed - no data loss with auto-playing irritating music, just
potential embarrassment / emotional annoyance.

> Although perhaps a little less
> discoverable as to the cause.

Very. Also the silent nature of this vulnerability means user might
not notice until long after damage is done.

> I doubt this will be an issue in practice

Perhaps. I might conclude similarly, yet I thought this was worth
raising as possible justification for enabling only in secure
connections.

Also this is a good concrete test-case of our blog post and indication
of direction re: features and secured connections.

> - as the page doesn't get to see the data its deleting, doing so would
> be pure vandalism, not worthy of an attacker who was trying to actually
> accomplish something.

Not pure vandalism. The user data loss is a side-effect of other incentives.

E.g. trivial "attacker" incentive: all those share-button-happy
news/media sites are likely to auto-copy URL + title of an article
you're reading when you do any user interaction with the article, in
the hopes that maybe you might paste the URL into an IM or email etc.
and send them some more traffic (given how much they annoyingly
sacrifice performance and page load/scroll speed with all their
like/+1/share/addthis etc. buttons, I see no reason to expect any
different behavior with this feature).

Tantek

[Doug Turner]

> On May 6, 2015, at 7:30 AM, Tantek Çelik <tan...@cs.stanford.edu> wrote:
>
>
> Not pure vandalism. The user data loss is a side-effect of other incentives.
>
> E.g. trivial "attacker" incentive: all those share-button-happy
> news/media sites are likely to auto-copy URL + title of an article
> you're reading when you do any user interaction with the article, in
> the hopes that maybe you might paste the URL into an IM or email etc.
> and send them some more traffic (given how much they annoyingly
> sacrifice performance and page load/scroll speed with all their
> like/+1/share/addthis etc. buttons, I see no reason to expect any
> different behavior with this feature).

Hi Tantek,

This is important. We could mitigate by requiring https, only allowing the top level document access these clipboard apis, and doorhangering the API. Thoughts?

Somewhat related, I do think bad actors should be treated harshly by all UAs. If we have a site or 3rd party load doing bad things, we could just decide not to load that content. We already do this for malware via safe browsing, and for tracking websites via Tracking Protection (about:config <about:config>, privacy.trackingprotection.enabled).

Doug

[Martin Thomson]

On Wed, May 6, 2015 at 8:42 AM, Doug Turner <do...@mozilla.com> wrote:
> This is important. We could mitigate by requiring https, only allowing the top level document access these clipboard apis, and doorhangering the API. Thoughts?

A doorhanger seems like overkill here. Making this conditional on an
"engagement gesture" seems about right. I don't believe that we
should be worry about surfing - and interacting with - strange sites
while there is something precious on the clipboard.

"Ask forgiveness, not permission" seems about the right balance here.
If we can find a way to revoke permission for a site that abuses the
privilege, that's better. (Adding this to about:permissions with a
default on state seems about right, which leads me to think that we
need the same for the fullscreen thing.)

[Anne van Kesteren]

On Wed, May 6, 2015 at 5:49 PM, Martin Thomson <m...@mozilla.com> wrote:
> A doorhanger seems like overkill here. Making this conditional on an
> "engagement gesture" seems about right. I don't believe that we
> should be worry about surfing - and interacting with - strange sites
> while there is something precious on the clipboard.

The worry was about your clipboard getting spammed, but I agree. HTTPS
does make sense so at least the network cannot get to your clipboard.

> "Ask forgiveness, not permission" seems about the right balance here.
> If we can find a way to revoke permission for a site that abuses the
> privilege, that's better. (Adding this to about:permissions with a
> default on state seems about right, which leads me to think that we
> need the same for the fullscreen thing.)

This I like a lot too, provided about:permissions moves into
about:preferences and gets a redesign... One can dream.


--
https://annevankesteren.nl/

[Tantek Çelik]

On Wed, May 6, 2015 at 5:49 PM, Martin Thomson <m...@mozilla.com> wrote:
> On Wed, May 6, 2015 at 8:42 AM, Doug Turner <do...@mozilla.com> wrote:
>> This is important. We could mitigate by requiring https, only allowing the top level document access these clipboard apis,

Thanks Doug. I think your first two suggestions are an excellent start.

Since we have no legacy to deal with, we can start conservative, and
wait for web developer feedback, and iterate accordingly. Thus, straw
proposal, let's use your first two:

* mitigate by requiring https
* only allowing the top level document access these clipboard apis

And then if developers complain about either of these restrictions in
practice, then hopefully they'll come with specific use-cases for us
to consider.

>> and doorhangering the API. Thoughts?
>

> A doorhanger seems like overkill here.

Agreed.

> Making this conditional on an
> "engagement gesture" seems about right.

Agreed on that too.

> I don't believe that we
> should be worry about surfing - and interacting with - strange sites
> while there is something precious on the clipboard.

Having lost clipboard data personally - I think this is an actual issue.

> "Ask forgiveness, not permission" seems about the right balance here.

I'd phrase it in a more user-centric manner, that is, a user interface
should be forgiving of user mistakes, rather than asking permission.

Thanks,

Tantek

[Mike Taylor]

Hi Tantek,

On 5/6/15 10:59, Tantek Çelik wrote:
> Since we have no legacy to deal with, we can start conservative, and
> wait for web developer feedback, and iterate accordingly.

We're behind IE10 and Chrome 43 in implementing this feature [1], so at
some level there will be existing content we need to deal with.
Interoperability with how they behave would be a win.

Ideally, whatever we do to protect our users can make it back to
Hallvord to spec and other implementers to match, otherwise
Flash-for-clipboard-access won't be going anywhere.

[1] <http://updates.html5rocks.com/2015/04/cut-and-copy-commands>

--
Mike Taylor
Web Compat, Mozilla

[Ehsan Akhgari]

> Result: loss of user data that user had put into the clipboard
> previously. This isn't possible with current DOM APIs and is a new
> vulnerability introduced by cut/copy.

Thanks for the clarification! I have actually already considered this,
and I don't think this is a problem that we need to deal with, at least
until we have some evidence that it is an actual problem in the wild.

Two points to note here:

1. The scenario that you're describing is already possible on the Web,
through Flash. However, I have not seen any evidence of this kind of
thing ever occurring in the wild. Given the fact that people have
literally had years to start trying to do this. Web sites do have an
incentive to not annoy users, and we have seen how they have largely
stopped doing annoying things such as blocking the context menu in the past.

2. Even if we decided that this is a serious issue that we need to
solve, there is no good solution here. Let's look at some of the
suggestions in this thread:

* Directly promoting the user is a horrible user experience, and given
that it is practically impossible to describe what we're asking for them
(many users may not even know what a "clipboard" is, since it has never
been exposed in a user-facing way in any OS that I've seen at least),
and also because it could be an annoying and pointless question to ask:
"Would you like website X to be able to copy text so that you can paste
it elsewhere?" "Why would I not want to allow that? Where is the
Whatever Button?". :-)

* Having a permissions for this is a similarly horrible user experience
for similar reasons to prompting, except that we show the permission UI
at different times than the prompt UI. Also, if the permission is
granted by default, this does very little to protect any of our users
anyway.

* Restricting this API to resources loaded from a secure origin also
doesn't help in any way in practice. It doesn't address your original
concern _at all_ (since your malicious web site can easily get a
certificate and perform the same annoying operation), and a potential
network attacker MITMing your connection can inject a tiny Flash object
and script it. It will be a few more lines of code for the attacker to
write, and they would get a pretty solid attack for the majority of
desktop users, at least.

* It may be argued that this attack has not been possible through Web
APIs so far, so we should now do something about it now that the
implementation is moving from Flash to the browser engine. I think
that's a very theoretical view of the world, and is quite insufficient
if we believe that this is a real issue worth addressing. Also, a
variation of this attack has been possible through the clipboard events
on the Web without Flash for a while now. For example, if you press
your mouse cursor in a text area and without selecting anything, press
Cmd+C, you would typically expect for the contents of the clipboard to
remain unchanged. It is possible for a web app to put arbitrary data on
the clipboard in that case (and again, with this feature, we have seen
no evidence of abuse in the wild so far.)

* At least on desktop where Flash is widely available, the real value of
this API is giving people a good incentive to move away from using
Flash. If the Web alternative is an API that doesn't work in some cases
(be it because the user said no to a prompt, disabled a permission, or
if the web page is served from a non-secure origin), people will keep
using Flash for this, and that eliminates most of the benefit from this
effort. Even worse, they may start to serve the Flash based code only
to Firefox users, which puts them at an unfair disadvantage compared to
the users of other major browsers.


Based on the above, I am planning to expose this API without any
restrictions, since I think the current lack of evidence for this being
an issue in practice will likely prove to be a more reliable way to make
this decision rather than hypothesizing about what an attacker could
possibly do. I do realize that we may actually see this issue popping
up in the wild in the future, and I'm open to revisiting this decision
when we have such evidence at hand. Thankfully, it would be relatively
easy to change our behavior, and we will make sure to make our behavior
feature detectible through the document.queryCommandSupported() API.

Cheers,
Ehsan

[Anne van Kesteren]

On Wed, May 6, 2015 at 7:02 PM, Ehsan Akhgari <ehsan....@gmail.com> wrote:
> * Restricting this API to resources loaded from a secure origin also doesn't
> help in any way in practice. It doesn't address your original concern _at
> all_ (since your malicious web site can easily get a certificate and perform
> the same annoying operation), and a potential network attacker MITMing your
> connection can inject a tiny Flash object and script it. It will be a few
> more lines of code for the attacker to write, and they would get a pretty
> solid attack for the majority of desktop users, at least.

Flash will go away (to the extent it hasn't already on mobile), this
feature won't. We should offer better security than what came before.


--
https://annevankesteren.nl/

[Adam Roach]

On 5/6/15 10:49, Martin Thomson wrote:
> On Wed, May 6, 2015 at 8:42 AM, Doug Turner<do...@mozilla.com> wrote:

>> This is important. We could mitigate by requiring https, only allowing the top level document access these clipboard apis, and doorhangering the API. Thoughts?
> A doorhanger seems like overkill here. Making this conditional on an
> "engagement gesture" seems about right. I don't believe that we

> should be worry about surfing - and interacting with - strange sites
> while there is something precious on the clipboard.
>

> "Ask forgiveness, not permission" seems about the right balance here.

> If we can find a way to revoke permission for a site that abuses the

> privilege, that's better. (Adding this toabout:permissions with a

> default on state seems about right, which leads me to think that we
> need the same for the fullscreen thing.)

Going fullscreen also gives the user UI at the time of activation,
allowing them to manipulate permissions in an obvious way:

https://www.dropbox.com/s/c0sbknrlz4pbybk/Screenshot%202015-05-06%2011.33.42.png?dl=0

Perhaps an analogous yellow ribbon informing the user that the site has
copied data onto their clipboard, with buttons to allow them to prevent
it from happening in the future, would be a good balance (in particular
if denying permission restored the clipboard to its previous state) --
it informs the user and provides clear recourse without *requiring*
additional action.

--
Adam Roach
Principal Platform Engineer
a...@mozilla.com
+1 650 903 0800 x863

[James Graham]

We also need to make a browser that people want to use. This means not
regressing the UX compared to what came before, or being markedly worse
than other browsers. Adding prompt/permissions UI in this case seems
like it is just going to be yet another papercut that will annoy more
people than will be pleased because we prevent some rogue website having
an unwanted interaction with the clipboard.

[Adam Roach]

On 5/6/15 10:49, Martin Thomson wrote:
> On Wed, May 6, 2015 at 8:42 AM, Doug Turner <do...@mozilla.com> wrote:
>> This is important. We could mitigate by requiring https, only allowing the top level document access these clipboard apis, and doorhangering the API. Thoughts?
> A doorhanger seems like overkill here. Making this conditional on an
> "engagement gesture" seems about right. I don't believe that we
> should be worry about surfing - and interacting with - strange sites
> while there is something precious on the clipboard.
>
> "Ask forgiveness, not permission" seems about the right balance here.
> If we can find a way to revoke permission for a site that abuses the

> privilege, that's better. (Adding this to about:permissions with a

> default on state seems about right, which leads me to think that we
> need the same for the fullscreen thing.)

Going fullscreen also gives the user UI at the time of activation,

allowing them to manipulate permissions in an obvious way.

[Ehsan Akhgari]

On 2015-05-06 1:08 PM, Anne van Kesteren wrote:
> On Wed, May 6, 2015 at 7:02 PM, Ehsan Akhgari <ehsan....@gmail.com> wrote:
>> * Restricting this API to resources loaded from a secure origin also doesn't
>> help in any way in practice. It doesn't address your original concern _at
>> all_ (since your malicious web site can easily get a certificate and perform
>> the same annoying operation), and a potential network attacker MITMing your
>> connection can inject a tiny Flash object and script it. It will be a few
>> more lines of code for the attacker to write, and they would get a pretty
>> solid attack for the majority of desktop users, at least.
>
> Flash will go away (to the extent it hasn't already on mobile), this
> feature won't. We should offer better security than what came before.

Sure, but this argument doesn't really work in the present tense where
Flash has actually not gone away, and is _the_ standard way for copying
text to the clipboard.

[Anne van Kesteren]

On Wed, May 6, 2015 at 6:40 PM, Adam Roach <a...@mozilla.com> wrote:
> Going fullscreen also gives the user UI at the time of activation, allowing
> them to manipulate permissions in an obvious way.

Note that we're changing that:

https://bugzilla.mozilla.org/show_bug.cgi?id=1129061

> Perhaps an analogous yellow ribbon informing the user that the site has
> copied data onto their clipboard, with buttons to allow them to prevent it
> from happening in the future, would be a good balance (in particular if
> denying permission restored the clipboard to its previous state) -- it
> informs the user and provides clear recourse without *requiring* additional
> action.

I like this idea. Although I wonder if users will understand what is happening.


--
https://annevankesteren.nl/

[Tom Schuster]

I think the ribbon would be really useful if it allowed the user to restore
the previous clipboard content. However this is probably not possible for
all data that can be stored in clipboards, i.e. files.

[James Graham]

On 06/05/15 18:22, James Graham wrote:

> On 06/05/15 18:08, Anne van Kesteren wrote:
>> On Wed, May 6, 2015 at 7:02 PM, Ehsan Akhgari
>> <ehsan....@gmail.com> wrote:
>>> * Restricting this API to resources loaded from a secure origin also
>>> doesn't
>>> help in any way in practice. It doesn't address your original
>>> concern _at
>>> all_ (since your malicious web site can easily get a certificate and
>>> perform
>>> the same annoying operation), and a potential network attacker
>>> MITMing your
>>> connection can inject a tiny Flash object and script it. It will be
>>> a few
>>> more lines of code for the attacker to write, and they would get a
>>> pretty
>>> solid attack for the majority of desktop users, at least.
>>
>> Flash will go away (to the extent it hasn't already on mobile), this
>> feature won't. We should offer better security than what came before.
>>
>>
>

> We also need to make a browser that people want to use. This means not
> regressing the UX compared to what came before, or being markedly worse
> than other browsers. Adding prompt/permissions UI in this case seems
> like it is just going to be yet another papercut that will annoy more
> people than will be pleased because we prevent some rogue website having
> an unwanted interaction with the clipboard.

Oh, sorry, this is about https. On desktop sites will just use flash
rather than https. On mobile they are at least as likely to not support
clipboard operations in Firefox as switch to https. Again, users will
just get the impression that Firefox is a slightly worse browser, for
relatively little gain.

[Justin Dolske]

On 5/6/15 10:02 AM, Ehsan Akhgari wrote:

> 1. The scenario that you're describing is already possible on the Web,
> through Flash. However, I have not seen any evidence of this kind of
> thing ever occurring in the wild. Given the fact that people have
> literally had years to start trying to do this. Web sites do have an
> incentive to not annoy users, and we have seen how they have largely
> stopped doing annoying things such as blocking the context menu in the
> past.

Well... Did Flash offer sites a way to to this without user interaction?

I don't know for sure, but I assumed it had to be invoked by a user
action... I remember a couple of popular URL shortener sites using Flash
for this, and they always required a conspicuously-extra click on a
"copy to clipboard" button. (Entering full-screen had the same
requirement too, IIRC.)

I think the "web sites do have an incentive to not annoy users" claim is
dubious too. Some sites certainly do, but we still see widespread
annoyance/abuse of features like popups, onbeforeunload traps, playing
unexpected audio in background tabs. And some legit sites (eg wendys.com
/ t-mobile.com) kind of abuse geolocation by prompting for it on every
page upon page load.

This isn't such a severe problem that we have to completely solve it
right away, but I'd hate to see us painted into a corner where we have
no options for mitigating abuse or giving our users control.

> 2. Even if we decided that this is a serious issue that we need to
> solve, there is no good solution here.

One off-the-cuff thought would be to place some reasonable restrictions
on the usage (tab must be in foreground, maybe in response to a user
interaction), and perhaps provide some (fairly subtle) UI indication of
when it's invoked. That at least gives the user a chance to see a
clearer cause/effect.

Or, along the vein of retroactively revoking permissions -- just keeping
a usage log somewhere. That at least enables motivated/SUMO users to be
able to discover what site is causing the problem, and then either
revoke it off or stop going there. Seems like kind of an interesting
idea that would scale to other seldomly-abused permissions...

Justin

[dgr...@github.com]

This is great news!

At GitHub, we have support in place for this feature in Chrome already. If you use a Canary build to visit the site, the copy buttons use the native JS `execCommand('copy')` API rather than Flash.

Although IE 11 supports this API as well, we have not enabled it yet. The browser displays a popup dialog asking the user for permission to copy to the clipboard. Hopefully this popup is removed in Edge so we can start using JS there too. I just haven't had a chance to test with it yet.

Right now, there isn't a reliable way to feature detect for this API in JS. We use user agent detection instead, just for this feature. Any suggestions here would be much appreciated.

It's exciting to see native copy-to-clipboard coming to Firefox. We'll follow along in Bugzilla and enable it on github.com when it's ready!

David

> among web sites. Sites such as Github currently use Flash in order to

> allow people to copy text to the clipboard by clicking a button in their UI.
>

> Cheers,
> --
> Ehsan

[Gervase Markham]

On 06/05/15 18:36, Tom Schuster wrote:
> I think the ribbon would be really useful if it allowed the user to
> restore the previous clipboard content. However this is probably not
> possible for all data that can be stored in clipboards, i.e. files.

Which is why we wouldn't overwrite the clipboard until the permission
was granted :-)

Gerv

[Jonas Sicking]

On Wed, May 6, 2015 at 8:42 AM, Doug Turner <do...@mozilla.com> wrote:
>

>> On May 6, 2015, at 7:30 AM, Tantek Çelik <tan...@cs.stanford.edu> wrote:
>>
>>
>> Not pure vandalism. The user data loss is a side-effect of other incentives.
>>
>> E.g. trivial "attacker" incentive: all those share-button-happy
>> news/media sites are likely to auto-copy URL + title of an article
>> you're reading when you do any user interaction with the article, in
>> the hopes that maybe you might paste the URL into an IM or email etc.
>> and send them some more traffic (given how much they annoyingly
>> sacrifice performance and page load/scroll speed with all their
>> like/+1/share/addthis etc. buttons, I see no reason to expect any
>> different behavior with this feature).
>
> Hi Tantek,
>

> This is important. We could mitigate by requiring https, only allowing the top level document access these clipboard apis, and doorhangering the API. Thoughts?

If news/media websites are likely to use the clipboard as an ad space,
why aren't we seeing that happening now? Remember that this is already
possible using flash. But to my knowledge this is not a big problem on
the web today. Even on websites that already take the performance hit
of initiating the flash plugin.

> Somewhat related, I do think bad actors should be treated harshly by all UAs. If we have a site or 3rd party load doing bad things, we could just decide not to load that content. We already do this for malware via safe browsing, and for tracking websites via Tracking Protection (about:config <about:config>, privacy.trackingprotection.enabled).

I definitely think it'd be cool if we had tracking-protection like
mechanisms to auto-block various APIs on websites that are bad actors.
For example it'd be cool to completely disable the ability to open
popups, even from user actions, on websites that use other user
interactions as an opportunity to create popups.

/ Jonas

[Jonas Sicking]

On Wed, May 6, 2015 at 10:08 AM, Anne van Kesteren <ann...@annevk.nl> wrote:
> On Wed, May 6, 2015 at 7:02 PM, Ehsan Akhgari <ehsan....@gmail.com> wrote:
>> * Restricting this API to resources loaded from a secure origin also doesn't
>> help in any way in practice. It doesn't address your original concern _at
>> all_ (since your malicious web site can easily get a certificate and perform
>> the same annoying operation), and a potential network attacker MITMing your
>> connection can inject a tiny Flash object and script it. It will be a few
>> more lines of code for the attacker to write, and they would get a pretty
>> solid attack for the majority of desktop users, at least.
>
> Flash will go away (to the extent it hasn't already on mobile), this
> feature won't. We should offer better security than what came before.

But the argument here is "if websites had access to write to the
clipboard, they will do horrible things X, Y and Z". However that
argument is fairly easily disproven by looking at websites that exist
today.

Also keep in mind that for any well behaving websites, limiting the
ability to write to the clipboard is an annoyance for users. The
reason this feature is getting added is because *users* are annoyed
that they have to use keyboard shortcuts to copy data. I would argue
that users visit far more well behaving websites, than once that don't
care about user experience.

Like Ehsan, I don't see what advantages limiting this to https brings?

/ Jonas

[Adam Roach]

Well, that makes it scantly better than a doorhanger, which is what
Martin was objecting to (and I agree with him). The model that we really
want here is "this thing happened, click here to undo it" rather than
"this think is about to happen, but won't unless you take additional
action." I think this position is pretty strongly bolstered by Dave
Graham's message about GitHub behavior: "Although IE 11 supports this

API as well, we have not enabled it yet. The browser displays a popup
dialog asking the user for permission to copy to the clipboard.
Hopefully this popup is removed in Edge so we can start using JS there too."

Basically, requiring the extra step of requiring the user to click on an
"okay, do it" button is high enough friction that the function loses its
value.

In any case, we should have a better technical exploration of the
assertion that restoring a clipboard isn't possible in all cases before
we take it as given. A cursory examination of the OS X clipboard API
leads me to believe that this would be trivially possible (I believe we
can just store the array of pasteboardItems from the NSGeneralPBoard off
somewhere so that they can be moved back if necessary). I'd be a little
surprised if this weren't also true for Linux and Windows.

[Mike Taylor]

Hey David,

On 5/6/15 13:09, dgr...@github.com wrote:
> Although IE 11 supports this API as well, we have not enabled it yet. The browser displays a popup dialog asking the user for permission to copy to the clipboard. Hopefully this popup is removed in Edge so we can start using JS there too. I just haven't had a chance to test with it yet.

Thanks for mentioning this--I suspect other sites would also fall back
to Flash if our UX is similarly annoying.

> Right now, there isn't a reliable way to feature detect for this API in JS. We use user agent detection instead, just for this feature. Any suggestions here would be much appreciated.

You can use the document.queryCommandSupported()[1] or
document.queryCommandEnabled()[2] APIs to check for support.

[1]
<https://developer.mozilla.org/en-US/docs/Web/API/Document/queryCommandSupported>
[2]
<https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIDOMNSHTMLDocument#queryCommandEnabled%28%29>

[Gervase Markham]

On 06/05/15 19:38, Adam Roach wrote:
> action." I think this position is pretty strongly bolstered by Dave

> Graham's message about GitHub behavior: "Although IE 11 supports this

> API as well, we have not enabled it yet. The browser displays a popup
> dialog asking the user for permission to copy to the clipboard.
> Hopefully this popup is removed in Edge so we can start using JS there too."

Is that popup one time only per site, or every time?

> Basically, requiring the extra step of requiring the user to click on an
> "okay, do it" button is high enough friction that the function loses its
> value.

Yeah, I can see that. OK.

Gerv

[Adam Roach]

On 5/6/15 13:32, Jonas Sicking wrote:
> Like Ehsan, I don't see what advantages limiting this to https brings?

In some ways, that depends on what we decide to define "new features" to
mean, and the release date of this feature relative to the date we
settle on in the announced security plan [1] of " Setting a date after
which all new features will be available only to secure websites."

If we use the example definition of "new features" to mean "features
that cannot be polyfilled," then this would qualify.

Keep in mind the thesis of that plan isn't that we restrict
security-sensitive features to https -- it's that /all new stuff/ is
restricted to https. If this falls under the definition of a "new
feature," and if it's going to be released after the embargo date, then
the security properties of clipboard manipulation don't really enter
into the evaluation.

____
[1]
https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/

[Neil Deakin]

On 2015-05-06 2:38 PM, Adam Roach wrote:
>
> In any case, we should have a better technical exploration of the
> assertion that restoring a clipboard isn't possible in all cases before
> we take it as given. A cursory examination of the OS X clipboard API
> leads me to believe that this would be trivially possible (I believe we
> can just store the array of pasteboardItems from the NSGeneralPBoard off
> somewhere so that they can be moved back if necessary). I'd be a little
> surprised if this weren't also true for Linux and Windows.

It isn't possible, no. Only the type of data is known to the clipboard.
The data itself is opaque and, in most cases, not actually determined
until it is pasted. You could handle some specific trivial cases, but i
don't think this is an avenue worth exploring.

[Martin Thomson]

On Wed, May 6, 2015 at 11:55 AM, Adam Roach <a...@mozilla.com> wrote:
> Keep in mind the thesis of that plan isn't that we restrict
> security-sensitive features to https -- it's that /all new stuff/ is
> restricted to https. If this falls under the definition of a "new feature,"
> and if it's going to be released after the embargo date, then the security
> properties of clipboard manipulation don't really enter into the evaluation.

This is perhaps a little early to be applying that rule, since we
haven't really gotten far with the discussion with other browser
vendors yet (though we've had some preliminary discussions).

I think that this is a great example of a feature that we could use to
test out the process for applying the policy. Though I can understand
why there might be some resistance, we don't find out much if we don't
ask.

I'm going to propose that we at least raise the question with other
browsers about restricting this feature to secure contexts. The
answer might help inform us on whether pursuing the deprecation plan
as outlined is feasible. Like Anne, I think that the benefit is
tangible to HTTPS-only, even it is small.

It would be a shame if the deprecation plan was spoiled simply because
features that were considered "too useful" got exemptions. In this
case, I'd say timing would be a valid reason for an exemption.

[Tantek Çelik]

On Thu, May 7, 2015 at 12:08 AM, Martin Thomson <m...@mozilla.com> wrote:
> On Wed, May 6, 2015 at 11:55 AM, Adam Roach <a...@mozilla.com> wrote:
>> Keep in mind the thesis of that plan isn't that we restrict
>> security-sensitive features to https -- it's that /all new stuff/ is
>> restricted to https. If this falls under the definition of a "new feature,"
>> and if it's going to be released after the embargo date, then the security
>> properties of clipboard manipulation don't really enter into the evaluation.
>
> This is perhaps a little early to be applying that rule, since we
> haven't really gotten far with the discussion with other browser
> vendors yet (though we've had some preliminary discussions).
>
> I think that this is a great example of a feature that we could use to
> test out the process for applying the policy.

I think this is the strongest argument for doing this.

> Though I can understand
> why there might be some resistance, we don't find out much if we don't
> ask.

Precisely.

The upside: we try out aspects of our proposed policy with very little risk.

The possible downside: we get negative feedback from developers, and
end up delaying the broader support (whether http or other fewer
restrictions) by one release. Given how long people have already
waited for this, is this potential delay really that harmful?
Especially in exchange for the upside.

> I'm going to propose that we at least raise the question with other
> browsers about restricting this feature to secure contexts.

This is a reasonable next step.

> The
> answer might help inform us on whether pursuing the deprecation plan
> as outlined is feasible.

Exactly, we get to start trying out parts of the plan at relatively
low risk. Like a drill of sorts.

> Like Anne, I think that the benefit is
> tangible to HTTPS-only, even it is small.

Based on the arguments presented in this thread, I have been convinced
of this too (tangible but small).

Thanks,

Tantek

[Ehsan Akhgari]

On 2015-05-06 1:40 PM, Justin Dolske wrote:
> On 5/6/15 10:02 AM, Ehsan Akhgari wrote:
>
>> 1. The scenario that you're describing is already possible on the Web,
>> through Flash. However, I have not seen any evidence of this kind of
>> thing ever occurring in the wild. Given the fact that people have
>> literally had years to start trying to do this. Web sites do have an
>> incentive to not annoy users, and we have seen how they have largely
>> stopped doing annoying things such as blocking the context menu in the
>> past.
>
> Well... Did Flash offer sites a way to to this without user interaction?

No, and as I said in the first email of this thread, neither are we.

> I think the "web sites do have an incentive to not annoy users" claim is
> dubious too. Some sites certainly do, but we still see widespread
> annoyance/abuse of features like popups, onbeforeunload traps, playing
> unexpected audio in background tabs. And some legit sites (eg wendys.com
> / t-mobile.com) kind of abuse geolocation by prompting for it on every
> page upon page load.

I never said that there are no websites that do annoying things. I did
say that they have an incentive to not annoy the user, because they
typically want the user to spend as much time on their website as
possible. Perhaps this is anecdotal, but I don't see examples of the
above abuses on the majority of websites that I visit.

Also, in this case I can safely make a stringer claim, because there has
been years of experience with an equivalent API.

> This isn't such a severe problem that we have to completely solve it
> right away, but I'd hate to see us painted into a corner where we have
> no options for mitigating abuse or giving our users control.

As I said in the email that you're replying to, this will actually not
paint us into a corner. We can always revisit this decision. Websites
will need to have fallbacks for older browsers for a while, and I don't
know if Safari plans to implement this yet.

>> 2. Even if we decided that this is a serious issue that we need to
>> solve, there is no good solution here.
>
> One off-the-cuff thought would be to place some reasonable restrictions
> on the usage (tab must be in foreground, maybe in response to a user
> interaction), and perhaps provide some (fairly subtle) UI indication of
> when it's invoked. That at least gives the user a chance to see a
> clearer cause/effect.

Please read the original email of the thread again. Perhaps I was not
clear enough. This API is going to be restricted to code that runs in
response to a user event (which means by definition it is restricted to
the foreground tab as well).

I don't think we shoiuld show a UI indication because a) such an
indication does not exist in any other app and b) it is not clear to me
what the user is supposed to do with such an indication.

> Or, along the vein of retroactively revoking permissions -- just keeping
> a usage log somewhere. That at least enables motivated/SUMO users to be
> able to discover what site is causing the problem, and then either
> revoke it off or stop going there. Seems like kind of an interesting
> idea that would scale to other seldomly-abused permissions...

Before we even begin to think about measures such as this, I would like
to see some evidence that this is a problem _in practice_.

[Ehsan Akhgari]

On 2015-05-06 6:48 PM, Tantek Çelik wrote:
> On Thu, May 7, 2015 at 12:08 AM, Martin Thomson <m...@mozilla.com> wrote:
>> On Wed, May 6, 2015 at 11:55 AM, Adam Roach <a...@mozilla.com> wrote:
>>> Keep in mind the thesis of that plan isn't that we restrict
>>> security-sensitive features to https -- it's that /all new stuff/ is
>>> restricted to https. If this falls under the definition of a "new feature,"
>>> and if it's going to be released after the embargo date, then the security
>>> properties of clipboard manipulation don't really enter into the evaluation.
>>
>> This is perhaps a little early to be applying that rule, since we
>> haven't really gotten far with the discussion with other browser
>> vendors yet (though we've had some preliminary discussions).
>>
>> I think that this is a great example of a feature that we could use to
>> test out the process for applying the policy.
>
> I think this is the strongest argument for doing this.

FWIW I don't really understand why this question turned into us looking
for projects as a test bed for the HTTP deprecation plans. I still
don't think you've demonstrated why this is a problem in practice, and
why restricting this API to TLS and leaving the possibility to leverage
Flash to *literally* achieve the same result on HTTP is an improvement.

>> Though I can understand
>> why there might be some resistance, we don't find out much if we don't
>> ask.
>
> Precisely.
>
> The upside: we try out aspects of our proposed policy with very little risk.
>
> The possible downside: we get negative feedback from developers, and
> end up delaying the broader support (whether http or other fewer
> restrictions) by one release. Given how long people have already
> waited for this, is this potential delay really that harmful?
> Especially in exchange for the upside.

What is it that you're actually proposing? I double read this thread
right now and I can't find a mention of a delay period. And what
problem are we solving again?

>> Like Anne, I think that the benefit is
>> tangible to HTTPS-only, even it is small.
>
> Based on the arguments presented in this thread, I have been convinced
> of this too (tangible but small).

What is the argument that convinced you? Protecting against someone
MITMing the connection of users who do not have Flash enabled to get
them to click somewhere on the page to copy something to the clipboard?
(I'm genuinely trying to understand what we're getting out of this.)

[Ehsan Akhgari]

On 2015-05-06 2:55 PM, Adam Roach wrote:
> On 5/6/15 13:32, Jonas Sicking wrote:
>> Like Ehsan, I don't see what advantages limiting this to https brings?
>
> In some ways, that depends on what we decide to define "new features" to
> mean, and the release date of this feature relative to the date we
> settle on in the announced security plan [1] of " Setting a date after
> which all new features will be available only to secure websites."
>
> If we use the example definition of "new features" to mean "features
> that cannot be polyfilled," then this would qualify.
>

> Keep in mind the thesis of that plan isn't that we restrict
> security-sensitive features to https -- it's that /all new stuff/ is
> restricted to https. If this falls under the definition of a "new
> feature," and if it's going to be released after the embargo date, then
> the security properties of clipboard manipulation don't really enter
> into the evaluation.

I admit that I didn't real the entire HTTP deprecation plan thread
because of the length and the tone of some of the participants, so
perhaps I missed this, but reading
<https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/>
seems to suggest that there is going to be a date and criteria for what
new features mean, but I see no mention of what that date is, or what
the definition of new features is.

So before we come up with a plan for that, I think the security
properties of clipboard manipulation are exactly what we need to take
into consideration here.

[Ehsan Akhgari]

On 2015-05-06 2:51 PM, Mike Taylor wrote:
> Hey David,
>
> On 5/6/15 13:09, dgr...@github.com wrote:

>> Although IE 11 supports this API as well, we have not enabled it yet.
>> The browser displays a popup dialog asking the user for permission to
>> copy to the clipboard. Hopefully this popup is removed in Edge so we
>> can start using JS there too. I just haven't had a chance to test with
>> it yet.
>

> Thanks for mentioning this--I suspect other sites would also fall back
> to Flash if our UX is similarly annoying.

Thanks David, this is really helpful. I also agree that showing UI for
this feature decreases the usability to a degree that the Flash
alternative may be preferred.

>> Right now, there isn't a reliable way to feature detect for this API
>> in JS. We use user agent detection instead, just for this feature. Any
>> suggestions here would be much appreciated.
>

> You can use the document.queryCommandSupported()[1] or
> document.queryCommandEnabled()[2] APIs to check for support.

So technically queryCommandSupported is the right way to feature detect
this. Note that currently our implementation of queryCommandSupported
is buggy and it returns true for all of the command names that we know
of, including "cut", "copy" and "paste". Over in
<https://bugzilla.mozilla.org/show_bug.cgi?id=1161721>, we'll fix our
implementation so that we return true for "cut" and "copy" and false for
"paste". So in Firefox, you'd be able to feature detect like this:

function isSupported() {
return document.queryCommandSupported("copy") &&
!document.queryCommandSupported("paste");
}

Chrome's implementation of this function is affected by
<https://code.google.com/p/chromium/issues/detail?id=476508>, but it
seems like it is getting fixed. I have not tested IE's implementation
of queryCommandSuported yet.

Cheers,
Ehsan

[Adam Roach]

On 5/6/15 20:32, Ehsan Akhgari wrote:
>> If this falls under the definition of a "new
>> feature," and if it's going to be released after the embargo date, then
>> the security properties of clipboard manipulation don't really enter
>> into the evaluation.
>
> I admit that I didn't real the entire HTTP deprecation plan thread
> because of the length and the tone of some of the participants, so
> perhaps I missed this, but reading
> <https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/>
> seems to suggest that there is going to be a date and criteria for
> what new features mean, but I see no mention of what that date is, or
> what the definition of new features is.

That's why there were two predicates qualifying the statement.

My point is that the answer to Jonas' question may -- and I'll emphasize
"may" -- turn on an overarching strategic security policy, rather than
the security properties of the feature itself.

[t...@bocoup.com]

I am not sure if this is the right avenue to raise concern (again) over not requiring a prompt. It seems that "user action" here implies that a user intended on having their clipboard destroyed intentionally. (Like requesting a SHA from GitHub).

However, I created a very basic demo here: http://jsfiddle.net/azgugmjb/3/ that shows how easy (in Chrome 43) it is to abuse the "user action". I really hope this shines some light on the potential for real world abuse. The user action in my demo is simply highlighting text. The use of `.select()` prevents the user from actually using the system keybinding for copying and will inject into their clipboard something other than what they intended.

[Ehsan Akhgari]

On 2015-05-20 9:41 PM, t...@bocoup.com wrote:
> I am not sure if this is the right avenue to raise concern (again) over not requiring a prompt. It seems that "user action" here implies that a user intended on having their clipboard destroyed intentionally. (Like requesting a SHA from GitHub).

No, I never meant to imply that. The only level of protection that
we're implementing is to make it impossible for the page to do this when
it's not being interacted with (for example, if you have the page open
in the background.)

> However, I created a very basic demo here: http://jsfiddle.net/azgugmjb/3/ that shows how easy (in Chrome 43) it is to abuse the "user action". I really hope this shines some light on the potential for real world abuse. The user action in my demo is simply highlighting text. The use of `.select()` prevents the user from actually using the system keybinding for copying and will inject into their clipboard something other than what they intended.

Yes, but you could construct a similar test case for copying something
through Flash by for example placing a transparent Flash movie in front
of that text and simulate the visual selection yourself, or rendering
the text in the Flash movie itself, etc.

And that is exactly the point I have been trying to make. The potential
for abuse definitely exists today, with Flash. And so far we have no
evidence that this is an issue in practice today. At the very least, by
allowing web developers to use the API implemented in the browser
engine, we will have some chance of reacting to this abusive behavior
becoming a problem in practice in the future, but if we hamper the user
experience by doing things such as displaying a prompt, Web developers
will just continue to use Flash at least on desktop where it's widely
available, and we wouldn't have a good way to react to this problem if
it proves to be a practical issue.

Therefore, I remain unconvinced that we need to display a prompt for
this API.

Cheers,
Ehsan

[Robert O'Callahan]

On Sat, May 23, 2015 at 5:21 AM, Ehsan Akhgari <ehsan....@gmail.com>
wrote:

> And that is exactly the point I have been trying to make. The potential
> for abuse definitely exists today, with Flash. And so far we have no
> evidence that this is an issue in practice today. At the very least, by
> allowing web developers to use the API implemented in the browser engine,
> we will have some chance of reacting to this abusive behavior becoming a
> problem in practice in the future, but if we hamper the user experience by
> doing things such as displaying a prompt, Web developers will just continue
> to use Flash at least on desktop where it's widely available, and we
> wouldn't have a good way to react to this problem if it proves to be a
> practical issue.
>
> Therefore, I remain unconvinced that we need to display a prompt for this
> API.
>

I think this is completely correct.

Rob
--
oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
owohooo
osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
oioso
oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
owohooo
osoaoyoso,o o‘oYooouo ofooooolo!o’o owoiololo oboeo oiono odoaonogoeoro
ooofo
otohoeo ofoioroeo ooofo ohoeololo.

[Jesper Kristensen]

Very nice, I am looking very much forward to using this.

It would be nice of you could also support paste. I agree that it is
more sensitive, so maybe you could go with a user prompt in that case?
The prompts as implemented in IE are horrible, but I think there could
be many better ways of doing it.

Here is one way I have thought of how a prompt could look like, since
you only allow it in relation to user interaction, you could make a
prompt that looks like a context menu for the element the user
interacted with, using a single word describing the action. I have
implemented a mockup at http://jsfiddle.net/vvjcgj5g/1/ but I am sure
Mozilla UX people could come up with better ways to do this. (My mockup
has a prompt for all three actions, but you could do it for paste only)

/Jesper Kristensen

[Ehsan Akhgari]

On 2015-05-23 5:02 AM, Jesper Kristensen wrote:
> Very nice, I am looking very much forward to using this.
>
> It would be nice of you could also support paste. I agree that it is
> more sensitive, so maybe you could go with a user prompt in that case?
> The prompts as implemented in IE are horrible, but I think there could
> be many better ways of doing it.
>
> Here is one way I have thought of how a prompt could look like, since
> you only allow it in relation to user interaction, you could make a
> prompt that looks like a context menu for the element the user
> interacted with, using a single word describing the action. I have
> implemented a mockup at http://jsfiddle.net/vvjcgj5g/1/ but I am sure
> Mozilla UX people could come up with better ways to do this. (My mockup
> has a prompt for all three actions, but you could do it for paste only)

Handling paste is a difficult topic, and I definitely don't have a good
answer yet.

Prompting for paste has two issues:

1. I'm not sure if we can express a useful message allowing the user to
make a good decision, since explaining the risk would be difficult. It
will also be an annoying prompt since we would have to show it every
time that the page wants to paste, since the contents of the clipboard
may be different. (It may be OK to persist a permission for websites
served from secure origins without undermining the user's security, but
still, the problem of asking the user a meaningful question to them
remains to be solved.)

2. The synchronous nature of the execCommand API mandates a modal
prompt, which is terrible for user experience, so we would probably need
some kind of an out of band permission request. But that may make the
permission prompt less obvious since the website may call into the
out-of-band permission requesting API at a time that is unrelated to the
user trying to paste, which will make it even less obvious what the page
is asking for.

On the question of the specific form the prompt would take, I'm very
hesitant to overlay something on top of the content, since web
developers typically hate it when the browser does that, as they may
have specific requirements and needs over what appears in the content
area. But that is probably a relatively easier issue to solve than the
above two problems.

Cheers,
Ehsan

[Karl Tomlinson]

> On 2015-05-23 5:02 AM, Jesper Kristensen wrote:
>> It would be nice of you could also support paste.

Ehsan Akhgari writes:

> Handling paste is a difficult topic, and I definitely don't have a
> good answer yet.
>
> Prompting for paste has two issues:

> 2. The synchronous nature of the execCommand API mandates a modal
> prompt, which is terrible for user experience, so we would
> probably need some kind of an out of band permission request.

A synchronous API would be a problem for pasting even without the
prompt, unless perhaps pasting data only from within the same
process.

Fetching the clipboard from another application, or process, is an
intrinsically asynchronous operation. Attempts have been made,
with varying degrees of success, to dress up the asynchronous
fetch as a synchronous operation. DataTransfer usage may have the
luxury of being able to pre-fetch the data in all formats before
dispatching the event referencing the DataTransfer, which despite
the inefficiencies can provide a synchronous API. I'm not
familiar with execCommand, but sounds like even that would not be
possible.

We shouldn't expose any more asynchronous operations in
synchronous APIs.

[Ted Mielczarek]

On Mon, May 25, 2015, at 11:04 AM, Ehsan Akhgari wrote:
> On 2015-05-23 5:02 AM, Jesper Kristensen wrote:

> > Very nice, I am looking very much forward to using this.
> >
> > It would be nice of you could also support paste. I agree that it is
> > more sensitive, so maybe you could go with a user prompt in that case?
> > The prompts as implemented in IE are horrible, but I think there could
> > be many better ways of doing it.
> >
> > Here is one way I have thought of how a prompt could look like, since
> > you only allow it in relation to user interaction, you could make a
> > prompt that looks like a context menu for the element the user
> > interacted with, using a single word describing the action. I have
> > implemented a mockup at http://jsfiddle.net/vvjcgj5g/1/ but I am sure
> > Mozilla UX people could come up with better ways to do this. (My mockup
> > has a prompt for all three actions, but you could do it for paste only)
>

> Handling paste is a difficult topic, and I definitely don't have a good
> answer yet.

Additionally, the 'paste' event from the spec already works, which seems
like it provides pretty useful functionality for webapps. The user can
use Ctrl+V or Edit->Paste or whatever existing UI mechanism the browser
has to trigger a paste, and the page can handle the event to do
something useful with the pasted data.

-Ted

[Jesper Kristensen]

Den 26-05-2015 kl. 13:13 skrev Ted Mielczarek:
> Additionally, the 'paste' event from the spec already works, which seems
> like it provides pretty useful functionality for webapps. The user can
> use Ctrl+V or Edit->Paste or whatever existing UI mechanism the browser
> has to trigger a paste, and the page can handle the event to do
> something useful with the pasted data.

The same can be said about cut and copy.

I don't think it will work for my use case. Here is my use case: I have
a web application that allows the user to upload tabular data. Users
most often prepare the data in Excel or other spreadsheet applications
before uploading the data. My application supports a CSV file upload,
but it is slow to use, since you have to copy the section you which to
upload into a separate spreadsheet, save it as a file, go into the web
application and find the same file, upload it, and then delete the
temporary file. You also get issues with character encoding when saving
as CSV from Excel. As a quicker solution the web application allows the
user to copy-paste the relevant section of their excel file into the web
application, which takes much fewer steps. However users often need to
paste large amounts of data (millions of cells), which will make the
browser freeze while it tries to render the pasted text in the textarea.
It would be much faster if I could just present a "Paste data" or
"Upload from clipboard" button, which could load the data from the
clipboard directly into a JavaScript string without first trying to
render it. I feel that doing this by handling the paste event on a text
area would be a confusing user experience, since you would have a
visible text area that would not work when you type into it, and it
looks like you would see your text when you paste, but you won't. So I
believe I need to trigger the paste event when the user clicks a button
in order to do this.

/Jesper Kristensen

[Neil Deakin]

On 2015-05-26 10:42 AM, Jesper Kristensen wrote:
It would be much faster if I could just present a "Paste data" or
> "Upload from clipboard" button, which could load the data from the
> clipboard directly into a JavaScript string without first trying to
> render it. I feel that doing this by handling the paste event on a text
> area would be a confusing user experience, since you would have a
> visible text area that would not work when you type into it, and it
> looks like you would see your text when you paste, but you won't. So I
> believe I need to trigger the paste event when the user clicks a button
> in order to do this.

Your use case is the intended use of the paste event and doesn't require
a separate button.

The following, for example, pastes only the first letter of the text on
the clipboard:

<input onpaste="this.value =
event.clipboardData.getData('text/plain')[0]; event.preventDefault()">


What you can't do though is have two separate types of pastes, such as a
normal Paste and a Paste Without Formatting type of option, although you
could workaround this with a toggle that needs to be clicked first.

[Ehsan Akhgari]

On 2015-05-26 10:42 AM, Jesper Kristensen wrote:

People have used tricks with invisible text areas for other similar use
cases. One example that comes to my mind is some editor widgets which
place a transparent text area where the current caret should be in order
to paint the caret and also receive an input event when the user types a
character, but of course this is a gross hack at best...

[dgr...@github.com]

We enabled native copy-to-clipboard on github.com today for Firefox Nightly visitors. The copy buttons no longer use a Flash widget in Nightly or Chrome!

Thanks so much for working on this, Ehsan.

David