Bug 11335 - execCommand("Paste") not allowed
Summary: execCommand("Paste") not allowed
Status: REOPENED
Alias: None
Product: WebKit
Classification: Unclassified
Component: HTML Editing (show other bugs)
Version: 420+
Hardware: Macintosh OS X 10.4
: P2 Normal
Assignee: Nobody
URL:
Keywords: GoogleBug, InRadar
: 12243 (view as bug list)
Depends on:
Blocks: 7712 9915 25486
  Show dependency treegraph
 
Reported: 2006-10-17 16:14 PDT by Chris Petersen
Modified: 2008-01-29 19:58 PST (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Petersen 2006-10-17 16:14:37 PDT
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
Comment 1 Chris Petersen 2006-10-17 16:17:07 PDT
This is filed as <rdar://problem/4788399>.
Comment 2 David Harrison 2006-12-12 15:13:34 PST
Works for me with TOT.
Comment 3 Darin Adler 2007-04-26 16:57:09 PDT
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.
Comment 4 Justin Garcia 2007-05-14 15:28:37 PDT
*** Bug 12243 has been marked as a duplicate of this bug. ***
Comment 5 Frederico Caldeira Knabben 2007-06-12 03:37:04 PDT
(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?
Comment 6 Maciej Stachowiak 2007-09-22 03:54:38 PDT
It might be acceptable to allow Paste in response to a user action, but we'd have to consider the security implications.
Comment 7 Frederico Caldeira Knabben 2007-09-22 05:32:17 PDT
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".
Comment 8 Eric Seidel (no email) 2007-11-22 11:42:05 PST
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.
Comment 9 Frederico Caldeira Knabben 2007-11-23 02:52:27 PST
(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.
Comment 10 Luca Bruno 2007-12-09 01:31:57 PST
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.
Comment 11 Justin Garcia 2008-01-29 19:58:54 PST
*** Bug 12243 has been marked as a duplicate of this bug. ***