Flash-Free Clipboard for the Web | Hacker News Reader

Flash-Free Clipboard for the Web

hacks.mozilla.org

167 pointssmacktoward58 comments

I really appreciate this, as I had to jump through a lot of loops to do so a few years ago. But I think that the browser should display a small alert when this API is called (like the webcam, or microphone).

I suggested this two years ago! I'm glad it's happening. I do agree that a permission dialog might be appropriate.

http://stackoverflow.com/questions/14472526/will-there-ever-...

  > Google Chrome and Internet Explorer both also support this API. Chrome uses
  > the same restriction as Firefox (that it must be run in a user-initiated
  > callback). Internet Explorer allows it to be called at any time, except it
  > first prompts the user with a dialog, asking for permission to access the
  > clipboard.

Seems like IE does what you want.

> Seems like IE does what you want.

It makes me feel very confused that this is actually true.

I was so disappointed that every color picker website nowadays uses flash/zeroclipboard to only copy HEX color value (6 letters!). It's so slow and inefficient. I ended up making my own one using this clipboard API - http://0xrgb.com

Glad to see that FF now supports this API, too!

It fails silently on Safari, though.

Sorry, I don't have a Mac here to test, could you please file an issue here: https://github.com/zserge/palette (yes, 0xrgb.com is open source).

By "fails" - you mean it doesn't select/highlight the color string, nor it does copy it to clipboard?

Doesn't copy. No errors in console.

Might be fixed now. Can anyone confirm please?

On a mac, works for me.

Still fails silently in Safari 8.0.7 (10600.7.12) on Yosemite. (I had to load it in Chrome to understand what the intended behaviour was).

Still doesn't work.

I have noticed that the click doesn't even trigger the animation of the color box too.

Safari is available for Windows...

Yup it wipes out whatever important info I was saving in my clipboard without warning me what-so-ever

I guess I could put a megabytes into anyone's clipboard now when they click on any link on a website.

No, you can't do that. from the mozilla link, "Google Chrome and Internet Explorer both also support this API. Chrome uses the same restriction as Firefox (that it must be run in a user-initiated callback). Internet Explorer allows it to be called at any time, except it first prompts the user with a dialog, asking for permission to access the clipboard."

Clicking a link is a user-initiated callback. So yes, he can do exactly that. I wonder if mouse move is also user-initiated.

I prefer

    window.prompt("Press Ctrl-C then Enter", text);

I don't want sites to be able to randomly clear my clipboard.

I don't mind sites being able to send data to the clipboard, as long as 1) they have explicit permission, and 2) they can only do so in response to a user action.

But if 2 is the only restriction, they could trick you into clicking something (anything anywhere on the page), and then silently access your clipboard.

>Access your clipboard

There is no API for reading from the clipboard, just writing to it.

The benefits of having a flashless copy/cut function greatly outweigh the off chance some random site will copy something stupid to your clipboard if you interact with it.

execCommand[0] has a "paste" option, which pastes the content of the clipboard at the current insertion point. This allows for "reading" of the clipboard.

This article doesn't mention "paste" specifically, but the footnote[1] in the "paste" section says:

"[1] Before Firefox 41, clipboard capability needed to be enabled in the user.js preference file. See A brief guide to Mozilla preferences for more information. In Firefox 41 and later, clipboard capability are enabled by default in any event handler that is able to pop-up a window (semi-trusted scripts)."

This footnote is not attached to any other command, and thus "paste" is singled out. This could just be a documentation error, or maybe they didn't want to highlight that paste was also being enabled. I don't have a FF v41 in order to test what the actual behavior is.

[0] - https://developer.mozilla.org/en-US/docs/Web/API/Document/ex...

"paste" is not enabled for non-trusted scripts on FF 41+. A extensions' scripts can use "paste" since they are trusted scripts; but a webpage's script cannot.

I believe that footnote is a doc error, since copy/cut are enabled w/o user.js override on FF 41+.

I don't know if there is any current plans to make "paste" available for all scripts - I don't think there would be because of the obvious concerns.

There are no plans to make "paste" available to scripts. User's clipboards can contain too much sensitive information.

In theory, Firefox could track if the current clipboard data was put there by the same origin, and allow paste if and only if so. That might be useful.

The benefits of having a flashless copy/cut function greatly outweigh the off chance some random site will copy something stupid to your clipboard if you interact with it.

While using Flash just for clipboard copying is not ideal, it seems easier to block Flash and stop sites from doing this (and other annoying things Flash is known for, like ads and autoplaying videos...) than blocking small parts of JavaScript APIs integrated into the browser.

Which is why both are required, and why there's no paste, just cut/copy.

I consider it an OS-level deficiency that clipboard copy is destructive by default. The fact that no major OS has multi-clipboard out of the box in 2015 is shameful.

By major you mean Windows and Mac? I know Linux has had tools to do this for a long time (as far back as I can remember ever using KDE). Indeed it's very sad that Windows and Mac can't do what my cell phone can.

I mean by default. There are tools available for all platforms, but the user has to seek them out.

If you're on linux, there's Diodon, which can handle a list of your last 25 clipboard copies

https://en.wikipedia.org/wiki/Diodon_%28software%29

I consider it an OS-level deficiency that no OS supports a kill-ring as a global service.

On Windows, I've been using Ditto for years (http://ditto-cp.sourceforge.net/ / https://chocolatey.org/packages/ditto). It's amazing how differently you work when you can copy multiple things, then paste them all rather than copy-paste copy-paste copy-paste. Makes it nice to not have to worry about your clipboard being lost.

Even with multiple registers in Vim, I still can't get my mind to think that way. I just link everything with the system clipboard because it's easier to deal with. How do you comprehend all of that hidden information in memory? To me, it seems like a useful feature if you do or can use it, but for most users it's just extra complexity.

Even worse with vim is there are operations like delete which push to the register stack without you intending it, it makes it really difficult to keep track of where your stuff is without looking.

Other than mapping the unnamed register to the system clipboard, I usually use a few specific registers — "a, "b for cut/copy and paste, and "q, "w for macros. Would be interesting to see how other vim users do it.

Actually I'm glad that the clipboard throws stuff away. Otherwise it'd make me hesitant to use it for any sensitive.

I'd be interested in the primary copy operation storing history by default, but also having a secondary copy operation that throws results away after some period of time - or maybe can only be pasted once?

I think LastPass acts like that - when you copy a password, it will clear the clipboard after a short time.

Microsoft Office has had multi-clipboard for a while.

Anything involving modal dialogs is bad UX these days, especially considering the variety of platforms web code needs to run on. You don't have "CTRL+C" on a smartphone or tablet.

KDE has this out of the box, so I think you may refer to windows. I am using this with great pleasure http://www.outertech.com/en/clipboard-history :)

I make a text editor that runs in a texture on a 3D object in the browser. I have a text area hidden in the background that technically holds focus and all clipboard operations go through it.

I was hoping this would let me get rid of that crufty text area. It's a serious quality and performance liability, and in certain special cases even ruins the UX. But it looks like that is not the case. Le sigh.

The execCommand("cut"/"copy") API is only available during a user-triggered callback, such as a click. If you try to call it at a different time, execCommand will return false, meaning that the command failed to execute.

Couldn't you bypass this by creating an invisible button, and then simulating a click event?

If they do it right, I imagine the source of the event would be tainted, so that only an actual click received from the OS would be allowed to propagate through.

I'm sure it's tricky to ensure this, though. Like pop-up blocking.

The engine can walk up the call stack and detect if the command was triggered by a click event.

There will always be a way to hide / obfuscate the action, making it seem to the browser that it was user-initiated.

I guess Mozilla have weighed up the convenience/security balance of browser control of the clipboard, and have put in a minimal protection scheme to make it clear that code should not play with it behind the user's back, but Mozilla knows that they can't really stop it.

> There will always be a way to hide / obfuscate the action, making it seem to the browser that it was user-initiated.

How? This security mechanism has been used for (among other things) popups for years now, and the only way it's been worked around is by attaching click handlers to links the user is likely to click.

Pop ups still occur, even on legitimate sites. Tripadvisor creates a pop-under when you click on a search result, for instance.

Basically, the user will click something at some point, the page can then unexpectedly put malicious stuff into the clipboard. No amount of protecting will stop this.

That's exactly what he just said.

Annoyingly this prevents using the result of an async operation.

Simulated click events are tracked as simulated. From the Javascript point of view there's not much difference unless synthetic/authentic click activation is involved (i.e. links, form submit, etc)

Can't this be used to poison the clipboard with bad code that once pasted in the wrong place will execute?

Just as much as the existing flash-based methods can.

Well I haven't used flash in years.

But Mozilla just re-enabled this exploit and I don't think it can be turned off.

There is a preference to disable the feature: dom.allow_cut_copy

Websites should not be able to overwrite the clipboard unless the action is user-initiated, from the blog post: The execCommand("cut"/"copy") API is only available during a user-triggered callback, such as a click. If you try to call it at a different time, execCommand will return false, meaning that the command failed to execute.

And? That still leaves a website open to doing that sort of thing on a click. (I can see it now: "like <website X> on Facebook today!" or somesuch copied to your clipboard every time you visit a site)

User-initiated != user-approved, at least not unless the user is specifically asked. (Like by, say, prompting allow/allowalways / deny / denyalways)

Thank you developers and all, but I don't think I had much trouble copying text before. On the contrary, when I click on a field and it force select everything for me I get frustrated.

Trust me, selecting text is not a problem. I haven't seen a place where click to select was a life savior.

Reply on news.ycombinator.com