Bug 11335 – execCommand("Paste") not allowed

• Component: HTML Editing
• Status: REOPENED

[Chris Petersen]

10/17/06 2:53 PM Chris Petersen:
* SUMMARY
I believe this might be a known issue already but filing just in case.

Paste toolbar icon doesn't function. Text that was copied to the clipboard doesn't get pasted into the document after I click the paste toolbar icon.

* STEPS TO REPRODUCE
1. With r17089 , login to your Writely account (Google Docs & Spreadsheet)
2. Create a new document
3. Type some text in your document body. Select it all and click the Copy toolbar icon.
4. Now, click the Paste toolbar icon.  Copied text doesn't get pasted into the document body.

* RESULTS
Copied text should get pasted back into the document body but doesn't

[Chris Petersen]

This is filed as <rdar://problem/4788399>.

[David Harrison]

Works for me with TOT.

[Darin Adler]

We don't support the paste command from JavaScript for security reasons. We don't want a site to be able to sniff the contents of the pasteboard.

[Justin Garcia]

*** Bug 12243 has been marked as a duplicate of this bug. ***

(In reply to comment #3)
> We don't support the paste command from JavaScript for security reasons. We
> don't want a site to be able to sniff the contents of the pasteboard.
> 

There are web applications, like FCKeditor, where users really expect to have such kinds of features available. What should we do in such cases?

Wouldn't it be a much better to display "The application is trying to access your clipboard information. Do you want to give access to it?", holding the execCommand  execution until the user response, returning "true" or "false" if the command has been executed?

[Maciej Stachowiak]

It might be acceptable to allow Paste in response to a user action, but we'd have to consider the security implications.

This is a common problem in all browsers.

I agree that clipboard data may contain strictly private information, like passwords. So, a browser must note make it easy to retrieve that information, but should also make it impossible if the user wanted it.

Today, only IE6- places no limits to it. It is quite simple to retrieve the clipboard data with it, and no restrictions are imposed. A very insecure thing.

My idea is making things similar to popup blockers. Once a JavaScript application tries to access the clipboard, a Yes/No alert box is presented to the user, stating that the app wants to retrieve data from the clipboard. A nice "Don't ask me again for www.example.com" checkbox could also be available, which saves the user preference. Like popups, the user should have some way to reset it too.

IE7 has implemented a similar thing. It is quite buggy though. Also, it doesn't have the checkbox to save the preference for the domain, but it doesn't ask it again for the same page if the user says "Yes".

[Eric Seidel (no email)]

Dialog boxes are generally a very bad thing for user interaction.  Clearly Google worked around this somehow if Harrison closed this as "works for me" a year ago.

(In reply to comment #8)
> Dialog boxes are generally a very bad thing for user interaction.  Clearly
> Google worked around this somehow if Harrison closed this as "works for me" a
> year ago.

The current workaround used by Google is displaying an alert saying - "Your browser does not allow access to your computer's clipboard" - which is actually not a workaround to the problems explained in this ticket.

Maybe Harrison could clarify this WFM.

[Luca Bruno]

Qt has a JavascriptCanAccessClipboard setting which would set DOMPasteAllowed (don't know if this is the correct setting).

I think such setting would be the best way for the user, just like any other setting.

[Justin Garcia]

*** Bug 12243 has been marked as a duplicate of this bug. ***