689590 - Implement the clipboardData property for copy/paste events when the user presses the respective key combinations

Status: RESOLVED DUPLICATE of bug 407983

(Core :: DOM: Editor, defect)

Description

[Felipe Heidrich]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20100101 Firefox/6.0.2
Build ID: 20110902133214

Steps to reproduce:

I'm trying to implement rich editor using contentEditable for the Orion Project (http://orion.eclipse.org).

I need to be able read and write text content to the clipboard, within and without clipboard events (at some point we would like to have our own context menu).

The situation keeps changing but currently it is as follow:
On IE, I can  always read and write to the clipboard
window.clipboardData.getData("Text");
window.clipboardData.setData("Text", text);

Chrome/Safari, from the paste event handler I can read the clipboard
event.clipboardData.getData("text/plain");
(but I can't write to the clipboard in the copy/cut event handler)

Firefox does not have a clipboardData. So we started hacking  alternatives:

1) Using Flash (ZeroClipboard for example), this is a no go for us.
2) UniversalXPConnec, also a no go
3) document.execCommand, also needs the user the grant special permission to the site (no go)
4) Change the selection during clipboard events.
That works most of the time. The idea is, during a paste event:
- change the selection to an empty html element (a DIV for example)
- set a timeout, and return
- the default paste handler pastes the clipboard content in the html element.
- the timeout gets called, the content of the html element is extracted, the selection is restored 
The problem: I need a text transfer, not a html transfer. So I am left with the task to convert html to text and that is not easy.
Similar strategy is used to implement copy and cut.
5) Same as 4, but use a text area instead of a DIV.
- The text area takes care of the html to text conversion.
- Switching the focus to the textArea during clipboard events is problematic (puts the textArea in a bad state and the paste gets the wrong content - possibly a bug in Firefox 4 as this used to work on Firefox 3).

Currently we are using (4) for copy and cut, and for paste a variation of (5) where the focus is assigned to the textArea in the keyDown event of Ctrl+V that precedes the paste event.

We need a better clipboard implementation for Firefox.  I understand that this request has security implication, but the needs of new web applications have overgrown the current support of textArea and contentEditable. New APIs are needed.

Thank you

Comment 1

[(no longer active)]

Firstly, does the textarea bug that you're mentioning happen in Firefox 7 as well?  If yes, can you please file that separately?

We recently talked to WebKit folks about this problem.  Seems like the only solution that won't have security implications is to provide copy/paste events when users press the keyboard combination with the clipboardData property.  Jonas, I'm pretty sure we had an existing bug on that, do you remember?

Comment 2

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Sorry, I don't know what's on file and what's not.

Comment 3

[Felipe Heidrich]

(In reply to Ehsan Akhgari [:ehsan] from comment #1)
> Firstly, does the textarea bug that you're mentioning happen in Firefox 7 as
> well?  If yes, can you please file that separately?

Okay, I will isolate the problem in a simple snippet and open a separate problem report for it.

> We recently talked to WebKit folks about this problem.  Seems like the only
> solution that won't have security implications is to provide copy/paste
> events when users press the keyboard combination with the clipboardData
> property. 

That would help a lot.
Note that clipboard events are also generated by the menu bar/context menu.
In our case, we are not using native context menu. If we ever decide to use a custom context menu in the editor we would not be able to use this solution to implement clipboard action in the menu.

Comment 4

[(no longer active)]

(In reply to Felipe Heidrich from comment #3)
> > We recently talked to WebKit folks about this problem.  Seems like the only
> > solution that won't have security implications is to provide copy/paste
> > events when users press the keyboard combination with the clipboardData
> > property. 
> 
> That would help a lot.
> Note that clipboard events are also generated by the menu bar/context menu.
> In our case, we are not using native context menu. If we ever decide to use
> a custom context menu in the editor we would not be able to use this
> solution to implement clipboard action in the menu.

We can allow those events if the copy/paste operation is initiated from the browser UI, but for custom web app provided context menus, I believe that the problem doesn't yet have a clear solution which also addresses the security implications.  :(

Comment 5

[Mihai Sucan [:msucan]]

(In reply to Ehsan Akhgari [:ehsan] from comment #4)
> (In reply to Felipe Heidrich from comment #3)
> > > We recently talked to WebKit folks about this problem.  Seems like the only
> > > solution that won't have security implications is to provide copy/paste
> > > events when users press the keyboard combination with the clipboardData
> > > property. 
> > 
> > That would help a lot.
> > Note that clipboard events are also generated by the menu bar/context menu.
> > In our case, we are not using native context menu. If we ever decide to use
> > a custom context menu in the editor we would not be able to use this
> > solution to implement clipboard action in the menu.
> 
> We can allow those events if the copy/paste operation is initiated from the
> browser UI, but for custom web app provided context menus, I believe that
> the problem doesn't yet have a clear solution which also addresses the
> security implications.  :(

Still, even in such case, it would allow us, as integrators of Orion, to build our own context menu that can generate a native paste event which would work with Orion. It would be a great win for us, on the Firefox side.

Felipe: can't Orion allow a native textarea context menu? Like Ace does. That would have select all, cut, copy and paste native menu items and it would work nicely.

That would leave the custom context menu problem to be solved at a later time, and by those who use the Orion base code. Orion itself could just provide an option for allowing a custom context menu instead of the native one. (this is the case with Ace)

(at least until a solution for the security implications with custom menu items and clipboard events is found)

Comment 6

[Felipe Heidrich]

> Still, even in such case, it would allow us, as integrators of Orion, to
> build our own context menu that can generate a native paste event which
> would work with Orion. It would be a great win for us, on the Firefox side.
> 
Good, 

> Felipe: can't Orion allow a native textarea context menu? Like Ace does.
> That would have select all, cut, copy and paste native menu items and it
> would work nicely.
> 
because most of the actions on the native context menu will not work.
take select all for example.
When select all is fired, the ua selects all the text in the container.
Differently for copy and paste, for select all there is no event or anything for us to get in the way and customize action.
So, the users uses select all followed by copy, the action will select and copy only the visible text (the text in the viewport, cause that is all the text the ua knows). That is wrong, it should have select the copied the entire content for the document.
Likewise, other action like undo/redo will have similar problems.
(note that in ace all these action are broken)

Our goal was to add a context menu with all action the user expects to see (with everything working obviously), plus orion-defined action like save etc. Unfortunately we are not there yet.

> That would leave the custom context menu problem to be solved at a later
> time, and by those who use the Orion base code. Orion itself could just
> provide an option for allowing a custom context menu instead of the native
> one. (this is the case with Ace)
> 
> (at least until a solution for the security implications with custom menu
> items and clipboard events is found)

In ACE the floating textarea used for input is not related with content text.
In orion we use contentEditable, so action like undo/redo/selectAll would actually change content in a visible manner. Even worse, it would leave the dom in a state that would cause the textView to fail in unexpected ways.
In our design, only the textview is allowed changing the dom and selection.

Comment 7

[Felipe Heidrich]

See 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=361180
https://bugzilla.mozilla.org/show_bug.cgi?id=694767

Our current paste hack also doesn't work :-(

Comment 8

[(no longer active)]

Bug 407983 has already been filed for this.