[Webkit-unassigned] [Bug 47482] Add webkitGetDataBlob/webkitSetDataBlob to event.dataTransfer

[bugzilla-daemon at webkit.org]

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





--- Comment #6 from Daniel Cheng <dcheng at chromium.org>  2010-10-15 14:29:37 PST ---
(In reply to comment #4)
> (From update of attachment 70437 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=70437&action=review
> 
> > WebCore/ChangeLog:9
> > +        copy-and-paste or drag-and-drop in WebKit.
> 
> Can you add a link to the proposal or discussion?

There wasn't much discussion, since no one ever replied to the post. But I linked it anyway.

> 
> > WebCore/ChangeLog:11
> > +        No tests. No functionality changed.
> 
> I think we should say that the test will be added when we have the stub implemented.
> 

Done.

> > WebCore/WebCore.xcodeproj/project.pbxproj:748
> > +		2EDEF1F4121B0EFC00726DB2 /* BlobData.h in Headers */ = {isa = PBXBuildFile; fileRef = 2EDEF1EE121B0EFC00726DB2 /* BlobData.h */; settings = {ATTRIBUTES = (Private, ); }; };
> 
> Why do we need to change the settings? Do you mean to copy the header file to PrivateHeaders? If needed, please explain in ChangeLog.
> 

Done.

> > WebCore/dom/Clipboard.h:67
> > +        virtual PassRefPtr<Blob> webkitGetDataBlob(const String& type, bool& success) const = 0;
> 
> Can we simply return 0 to indicate failure, instead of introducing an extra boolean output parameter?
> 

I opted to follow the pattern in the IDL file, but I'm not opposed to changing it.

> > WebCore/dom/Clipboard.h:68
> > +        virtual bool webkitSetDataBlob(const String& type, PassRefPtr<Blob> data) = 0;
> 
> You can omit 'data' argument name.
> 

Done.

> > WebCore/dom/Clipboard.idl:41
> > +        [Custom] void webkitGetDataBlob(in DOMString type)
> 
> Do we need Custom attribute? I think probably we can remove it if we remove 'success' parameter Clipboard::webkitGetDataBlob?

I opted to follow the way existing code did it. I'm not really familiar with the IDL bindings, so it seemed safest to copy the existing pattern in the file.

> Do we consider adding a feature guard to wrap this new feature?

I did not consider this. Who defines these flags when you're building, say, the Chrome port?

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