[Webkit-unassigned] [Bug 40540] [chromium] Add new stubs for querying platform drag-and-drop and copy-and-paste data.

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=40540





--- Comment #20 from Darin Fisher (:fishd, Google) <fishd at chromium.org>  2010-06-15 14:54:09 PST ---
(In reply to comment #17)
> > WebKit/chromium/public/WebKitClient.h:90
> >  +      virtual bool clipboardWriteData(const WebDragData& data) { return false; }
> > shouldn't this method be declared on WebClipboard instead?  that
> > interface exists to collect all of the clipboard related callbacks
> > to the embedder.
> > 
> 
> Why do we go through all that indirection? I find it hard to follow personally:
> ChromiumBridge->WebKitClient->WebClipboard->WebClipboardImpl->renderer glue, which in the end, just calls an IPC. Is this for the test shell?
> 
> Isn't it simpler to just say:
> ChromiumBridge->WebKitClient->IPC?

It helps provide some grouping to WebKitClient.  I think it would
become a giant mess to have everything flattened into a single
implementation.


> > WebKit/chromium/public/WebKitClient.h:92
> >  +      virtual WebVector<WebString> dataTransferGetFilenames(WebDataTransfer::Source source) { return WebVector<WebString>(); }
> > but, perhaps WebDataTransfer should be a struct with fields data, metadata, and filenames?  then you could just call a function on WebKitClient named getDataTransfer?  is there any reason why you would want the data and metadata but not the filenames?
> 
> No one needs the data until the drop actually happens. At that point, the drop target usually only cares about one specific flavor of data. Filenames happens to be a flavor of data that has its own special accessor, since the HTML5 draft doesn't specify a MIME type for it.

OK

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.