|Product:||WebKit||Reporter:||Ryosuke Niwa <rniwa>|
|Component:||HTML Editing||Assignee:||Ryosuke Niwa <rniwa>|
|Severity:||Enhancement||CC:||abarth, adele, ap, darin, dcheng, enrica, justin.garcia, ojan, tonikitoo, tony|
|Version:||528+ (Nightly build)|
|Bug Depends on:|
Description Ryosuke Niwa 2011-01-13 17:51:07 PST
Comment 1 Ryosuke Niwa 2011-01-13 18:12:28 PST
Created attachment 78881 [details] proof of concept on Mac port
Comment 2 Ryosuke Niwa 2011-01-13 21:46:43 PST
Comment on attachment 78881 [details] proof of concept on Mac port View in context: https://bugs.webkit.org/attachment.cgi?id=78881&action=review > WebKit2/WebProcess/WebPage/WebPage.cpp:1189 > - settings->setDOMPasteAllowed(store.getBoolValueForKey(WebPreferencesKey::domPasteAllowedKey())); > + > + m_isCopyCutEnabled = store.getBoolValueForKey(WebPreferencesKey::domPasteAllowedKey()); I don't know what's the correct thing to do for WebKit2. Could someone familiar with WebKit2 comment on what I should be doing here? Enrica?
Comment 3 Alexey Proskuryakov 2011-01-13 23:24:06 PST
Comment 4 Adam Barth 2011-01-14 23:48:18 PST
We discussed this on IRC. Our current thinking is to add SecurityOrigin::canPaste style functions and use a whitelist.
Comment 5 Ryosuke Niwa 2011-02-07 21:29:11 PST
After another discussion with abarth and othermaciej, I think we're going back to the original plan of adding an method to EditorClient.
Comment 7 Ryosuke Niwa 2011-02-14 18:30:04 PST
Hi, could someone review my patch? This patch or some alternative mechanism to control copy & paste per origin is required for a Chromium feature.
Comment 8 Adam Barth 2011-02-14 18:50:08 PST
Comment on attachment 81592 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=81592&action=review > Source/WebCore/editing/EditorCommand.cpp:1129 > + EditorClient* client = frame->editor()->client(); > + if (client && client->canCopyCut()) > + return true; It's strange that if the client returns false from canCopyCut, the web page might still be able to copy or cut. That's why I recommended the design we use for allowPlugins where we pass the default as a parameter. That way its easy for the client to accept the default and also easy for the client to have the final say.
Comment 9 Ryosuke Niwa 2011-02-14 22:29:34 PST
Created attachment 82415 [details] Fixed per Adam's comment
Comment 10 Adam Barth 2011-02-14 22:38:17 PST
Comment on attachment 82415 [details] Fixed per Adam's comment View in context: https://bugs.webkit.org/attachment.cgi?id=82415&action=review > Source/WebKit2/WebProcess/WebCoreSupport/WebEditorClient.cpp:256 > + notImplemented(); These probably don't need notImplemented(). These are perfectly fine implementations. > Source/WebKit2/WebProcess/WebCoreSupport/WebEditorClient.h:78 > + virtual bool canCopyCut(bool defaultValue) const; > + virtual bool canPaste(bool defaultValue) const; Are these the same semantically as the functions below? If not, consider renaming them to allowPaste, etc.
Comment 11 Ryosuke Niwa 2011-02-14 22:55:50 PST
Thanks for the review! (In reply to comment #10) > (From update of attachment 82415 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=82415&action=review > > > Source/WebKit2/WebProcess/WebCoreSupport/WebEditorClient.cpp:256 > > + notImplemented(); > > These probably don't need notImplemented(). These are perfectly fine implementations. Ok, will remove. > > Source/WebKit2/WebProcess/WebCoreSupport/WebEditorClient.h:78 > > + virtual bool canCopyCut(bool defaultValue) const; > > + virtual bool canPaste(bool defaultValue) const; > > Are these the same semantically as the functions below? If not, consider renaming them to allowPaste, etc. Semantics depends on each implementation because some client might always return true/false to indicate that copy/cut/paste are always possible. canUndo/canRedo are usually implemented to return true iff we have objects in the undo stack but clients are free to access control undo/redo per origin via these two functions as well.