I suggest using https://github.com/mojombo/clippy, this is what Gerrit uses also, note that browsers given the sandbox will not give you access to the system clipboard, all addons that allow copy to clipboard are using flash (if available)

It's very easy to add, especially if it's on one form.

http://zeroclipboard.org/#demo is the right solution -- Flash is required to reliably access the clipboard. This is what GitHub uses. (Clippy that Tal linked to hasn't been maintained since 2009.)

There are HTML5 api's for clipboard access, but I don't think anyone implements them (yet).

Flash doesn't have to be "required" -- only needed if you want to use the copy button :) Chrome comes with "Flash" bundled now, so only an issue for other browsers.

(In reply to Greg Sheremeta from comment #4)
> ...
> There are HTML5 api's for clipboard access, but I don't think anyone
> implements them (yet).

according to [1], it seems that Firefox fully supports this, IE too (using a non-standard method of interacting with the clipboard though [2]) and Chrome too, except the ClipboardEvent constructor (which I don't think that we need; to my understanding, in order to implement e.g. a 'copy' button, we need the clipboard methods, not clipboard events; please correct me if I am wrong). 

assuming we don't want to use flash for clipboard implementation, and based on the above: do you guys think that we can implement this by utilizing the HTML5 clipboard api after all?

[1] http://caniuse.com/#feat=clipboard

[2] https://msdn.microsoft.com/en-us/library/ie/ms535220(v=vs.85).aspx

I researched this quite a bit.

> according to [1], it seems that Firefox fully supports this, IE too (using a non-standard method of interacting with the clipboard though [2]) and Chrome too

The spec is at [2].

In [2], the only method given for accessing the clipboard is document.execCommand('copy') and document.execCommand('paste').

I've tried to get these to work in Chrome 41 and Firefox 36, but no luck. Google results suggest that this will only work in Chrome in a Chrome extension. So I believe [1] is wrong. Since I cannot get it to work, and since it's experimental and not documented at all, I don't think it's viable.

Google Docs automatically copies share URLs to the clipboard for me in Chrome. I debugged that, and turns out that is implemented via a Chrome extension for Google Docs. It doesn't auto copy in Firefox.

I think we're stuck using Flash if we want to do this. I'm not against using Flash -- either requiring it or suggesting it. It's had 99% market penetration since at least 2011. The only concern I have regarding security is that Adobe stopped developing Flash for Linux years ago. So everyone using Firefox on Linux has a really old Flash installed (although, Adobe supplies critical security fixes for it, but that won't last forever). All versions of Chrome come with the latest Flash bundled, even on Linux, so this is only an issue with Firefox on Linux. (On Fedora 20, my Chrome 41 has Flash 16, and my Firefox 36 has 11.2.)

There is an alternative open source Flash player for Firefox called Shumway. [3] We could probably get ZeroClipboard working with that. I tried it on Firefox 36, and ZeroClipboard doesn't work with it out of the box -- but I think we could get it working. A downside of using it is that it's marked as experimental.

[1] http://caniuse.com/#feat=clipboard
[2] http://www.w3.org/TR/clipboard-apis
[3] http://mozilla.github.io/shumway/

Thank you for the detailed information, Greg - very educational, and much appreciated. 

@Yaniv, it looks like we have a real issue introducing a clipboard-copy functionality, at least for Firefox on Linux, without using something experimental that doesn't necessarily work (HTML5, Shumway), or using something very old that we cannot necessarily reliably count on for the long term (Flash). 

Based on the information here, my recommendation is to not implement a 'copy' capability in the GUI; instead - it seems like we should rely on "Ctrl+C" and/or native browser context menu, where possible/needed. 

If you agree - this BZ should be closed. 
Otherwise - please let us know your thoughts on a recommended approach for implementation. 

Thanks.

(In reply to Einav Cohen from comment #8)
> Thank you for the detailed information, Greg - very educational, and much
> appreciated. 
> 
> @Yaniv, it looks like we have a real issue introducing a clipboard-copy
> functionality, at least for Firefox on Linux, without using something
> experimental that doesn't necessarily work (HTML5, Shumway), or using
> something very old that we cannot necessarily reliably count on for the long
> term (Flash). 
> 
> Based on the information here, my recommendation is to not implement a
> 'copy' capability in the GUI; instead - it seems like we should rely on
> "Ctrl+C" and/or native browser context menu, where possible/needed. 
> 
> If you agree - this BZ should be closed. 
> Otherwise - please let us know your thoughts on a recommended approach for
> implementation. 
> 
> Thanks.

Can we expose the browser 'copy'\'paste' command in our right click menus?
Because to my understanding our right click menus currently do not show this option.

Created attachment 1013666 [details]
context copy

Created attachment 1013667 [details]
google docs custom context 1

Created attachment 1013668 [details]
google docs custom context 2

> Can we expose the browser 'copy'\'paste' command in our right click menus?

Where we don't have a custom context menu, 'copy' is already there. See attached screenshot named 'context copy'.

Where we've implemented a custom context menu, yes, but only if you want to do one of the (poor) options in comment 7. Einav recommends *not* to in comment 8.

Note that Google Docs offers the options in its custom context menu, but then tells you to manually hit Ctrl-C and Ctrl-V when you click them. (Screenshots attached, 'google docs custom context 1' and 'google docs custom context 2')

Thanks, Greg - you're absolutely correct. 

One additional note: see bug 1194749, comment #2, in which I mention that UXD/PatternFly is going towards not using custom context menus (like the ones that we have now), which should allow us to utilize the browser context menu more easily throughout the GUI, once we will adopt PatternFly more comprehensively.

(In reply to Einav Cohen from comment #14)
> Thanks, Greg - you're absolutely correct. 
> 
> One additional note: see bug 1194749, comment #2, in which I mention that
> UXD/PatternFly is going towards not using custom context menus (like the
> ones that we have now), which should allow us to utilize the browser context
> menu more easily throughout the GUI, once we will adopt PatternFly more
> comprehensively.

So in 4.0 we will not have custom menus and therefore have the native broswer copy\paste?

once the grids in the GUI will adopt PatternFly, we expect to lose our custom context menus, therefore have the native browser context menu (that should contain copy/paste) instead, yes. 
[we will try to do it for 4.0, may end up being in 4.x - not sure]

(In reply to Einav Cohen from comment #16)
> once the grids in the GUI will adopt PatternFly, we expect to lose our
> custom context menus, therefore have the native browser context menu (that
> should contain copy/paste) instead, yes. 
> [we will try to do it for 4.0, may end up being in 4.x - not sure]

The context menus live on, but browsers now support copy/paste.
https://clipboardjs.com/
This should not be too difficult.

This bug has not been marked as blocker for oVirt 4.3.0.
Since we are releasing it tomorrow, January 29th, this bug has been re-targeted to 4.3.1.

after pf3 conversion things are easy to copy, not needed anymore