[Webkit-unassigned] [Bug 40515] Add a low-level platform abstraction for copy-and-paste and drag-and-drop data.

[bugzilla-daemon at webkit.org]

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





--- Comment #13 from Daniel Cheng <dcheng at chromium.org>  2010-06-30 17:08:31 PST ---
(In reply to comment #12)
> (From update of attachment 58549 [details])
> > +class ClipboardData : public RefCounted<ClipboardData> {
> 
> This seems fine, but I'm not sure why it's an abstract base class. Generally speaking the platform directory does not use runtime factories that vend objects of abstract base classes. I have seen other libraries that use this approach, but it has runtime costs that we prefer not to pay in WebKit.
> 
> The interface here looks generally OK in terms of what the functions are and the argument types, but the basic approach does not seem right.
> 
> An example of how we do this without virtual functions is in the FileChooser.h source file. Not sure that needs to be a reference-counted object, but otherwise it's a reasonable example. DragData.h is another example, although a particularly messy one.

The interface is virtual because there are two implementations for a given platform:
1. One implementation that lives under platform. This provides a read-only implementation of ClipboardData which wraps accessing native copy/paste and drag/drop data.
2. Another common implementation that lives in a location TBD. It is primarily intended for writing (in the cut/copy/dragstart events), though you can read from it as well.

The reason for creating two separate implementations like this is because I found the way the current Clipboard worked to be a little wonky:
- When starting drags, platform implementations of Clipboard simply allow data members to be set. At some point, DragClient::startDrag is called and the implementation atomically creates a data object and sets all data that will be in that drag.
- For copy/cut operations, Clipboard immediately writes back to the clipboard, so Clipboard contents won't be set atomically. Thus, we end up with Clipboard implementations that look like:
if (m_isForDragging) {
    m_foo = bar;
} else {
    // FIXME: Add Pasteboard support.
}
This is true for Windows WebKit, Chromium WebKit, and probably a number of other platforms as well.
- If writing drag data and copy data are abstracted by one generic object, then Clipboard becomes much simpler. Persisting data to the clipboard might look like this instead:
if (clipboard.isDirty()) {
    Pasteboard::clear();
    Pasteboard::writeData(clipboard);
}
This also has the bonus side effect that preventing a copy or cut no longer clears the Pasteboard contents, which follows IE behavior.

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