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).
> 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.
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
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."
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.
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.
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?
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.
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 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.
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.
"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.
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.
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.
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.
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.
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)
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.
