[Webkit-unassigned] [Bug 53727] Clone WebClipboard to be frame-specific

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu Feb 3 17:18:41 PST 2011


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





--- Comment #5 from Daniel Cheng <dcheng at chromium.org>  2011-02-03 17:18:41 PST ---
(In reply to comment #4)
> (From update of attachment 81142 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=81142&action=review
> 
> > Source/WebCore/ChangeLog:12
> > +        For drop operations, Chrome currently snapshots the data and copies it
> > +        into the renderer process. As we add more supported drag data types, the
> > +        copy will become increasingly expensive. Instead, we'd like to snapshot
> > +        data in the browser to reduce the amount of data copied and to support
> > +        Blob in DataTransferItem. In order to allow this, we associated
> 
> I'm sorry, I'm not sure I follow.  Is the copy you're referring to the IPC?  I thought the slow part was reading from the drag source?

It is, but given that Chrome doesn't actually wait for WebKit to finish drop handling before signaling the OS that the drop is complete, it's not possible to implement the original design on OS X. There probably would have been corner cases that failed on Windows as well. It worked well on Linux though. =)

> 
> When you say you snapshot data in the browser, you mean the browser process?  Wouldn't that still need to be copied over IPC?

Yes, but only the data requested (through getData or otherwise) would be copied over. This saves copying over any data we don't care about (for example, images).

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



More information about the webkit-unassigned mailing list