[webkit-dev] Refactoring the Clipboard class

[Darin Adler]

You mention some refactoring.

But the thing you mention here with the biggest significance is creating a WebKit-internal clipboard to augment the platform-specific clipboard mechanisms that work between processes and between WebKit and non-WebKit within a process.

I think that’s OK, but it does have a significant downside. If done in the most obvious way we will no longer have an easy way to test the system clipboard code paths. And those are used a lot, for example to copy from Safari to Mail on Mac OS X. I’m not sure that having duplicate code paths to optimize behavior inside the WebKit process is worth it, but it might be a worthwhile feature.

My main advice would be to do refactoring separately from behavior changes. And in steps that are as small as possible.

But clipboard is an area where we have some messy code so some work on it could help. Not the work you mentioned, but some even more basic refactoring and redesign. We have a major architecture mistake in our current Clipboard that should be fixed.

The Clipboard object itself is a DOM object, in dom/Clipboard.idl and dom/Clipboard.h. Unfortunately, this DOM object has platform-specific bits in the wrong directory. They are in the platform directory instead of being in the dom directory or per-platform dom subdirectories. The platform directory holds a separate module, which should have no knowledge of DOM at all. It’s not appropriate to have the platform-specific implementation of a dom class in the platform directory.

What we need is a lower level clipboard abstraction in the platform directory that the DOM Clipboard object can use. Think of this relationship as analogous to the relationship of the DOM Canvas graphics context to the platform directory GraphicsContext class. The new object should be in the platform directory and the one in the dom directory should use it. Most platform specifics could be factored out completely from the dom directory and the need for per-platform source files in that directory would be minimal.

Another cross-platform clipboard abstraction is in platform/Pasteboard.h. Unfortunately, it too does not belong in the platform directory in its current form. It has code that deals with the DOM and editing machinery that is not allowed in the platform module.

Straightening out these classes would be an important part of refactoring to clean up clipboard-related code. Code to map DOM to various platform-specific pasteboard formats belongs in the editing subdirectory in platform-specific files so we can cope with platform-specific formats, perhaps using code from the platform directory to help with other aspects of the platform-specific clipboard machinery. Code to implement the DOM clipboard object should remain in a directory other than platform, either the dom, editing, or html directory. A platform-independent abstraction to allow these other classes to be written cleanly with a minimum of platform-specific code should be in the platform directory.

    -- Darin