Since it doesn't look like https://bugs.webkit.org/show_bug.cgi?id=40515 is going anywhere, work around it in M6 by creating another setter function. It'd still be nice to take the changes in https://bugs.webkit.org/show_bug.cgi?id=40515 and get rid of this new function in the embedding layer, but that's not going to happen in M6.
Created attachment 61301 [details] Patch
Comment on attachment 61301 [details] Patch you need to update the ChangeLog file. it'd be helpful also if i could see how this new function will be used.
Created attachment 61419 [details] Patch Sorry, forgot to commit the changes for the ChangeLog. ClipboardChromium::setData (or ChromiumDataObject) will call ChromiumBridge::clipboard()->writeDataFlavor() directly when setting data for a copy/cut. As mentioned in bug 40515, it'd be nice if we had the equivalent of startDrag() for copy and cut, but I don't think that feature is going to make M6.
I think this would be easier to review if you had a chromium side change demonstrating how it's used.
Comment on attachment 61419 [details] Patch r- based on tony and darin's comments above.
(In reply to comment #4) > I think this would be easier to review if you had a chromium side change demonstrating how it's used. I'll try to post a patch for that this evening. I'm trying to separate my patches from each other right now, and it's a rather painful process. It's needed because drags and copies/cuts aren't written back to the system data object the same way. For drags: The drag controller starts a drag. The DOM receives a dragstart event and populates event.dataTransfer. The drag controller calls DragClient::startDrag(), which passes all the data that was set in event.dataTransfer to the Chromium side. For copy/cut: The editor clears the pasteboard before it does anything. Then a copy/cut event is dispatched to the DOM, and for each call to event.dataTransfer.setData(), data is immediately written back to the system pasteboard. There is no analogous version of DragClient::startDrag() for pasteboard operations. I wanted to add this, but haven't done so since I didn't receive feedback from Darin Adler. Since we must write back immediately, and the existing APIs are not rich enough, I added a new interface.
Created attachment 65628 [details] Patch
Comment on attachment 65628 [details] Patch I see, we're not using writeData yet (it looks like a stub on the chromium side). In that case, this seems fine. Don't forget to update webclipboard_impl.* on the Chromium side too.
Comment on attachment 65628 [details] Patch Clearing flags on attachment: 65628 Committed r66293: <http://trac.webkit.org/changeset/66293>
All reviewed patches have been landed. Closing bug.