Re: clipboard events

On Mon, Jan 31, 2011 at 12:00 PM, Ryosuke Niwa <rniwa@webkit.org> wrote:

> Making it live seems more efficient.  If we allowed arbitrary MIME types
> and spec'ed to always return the same data, then we must copy contents in
> the clipboard of all MIME types into some internal data structure.  This
> will create a huge performance bottle-neck because even if the page never
> called getData, we need to make copies of, say, a 5MB jpeg image and the
> corresponding 100MB bmp along with various other MIME types in the clipboard
> when firing paste or copy event.
>

The Windows model is to lock the clipboard while using it (via
OpenClipboard).  Leaving the clipboard locked while a script is running
doesn't work well, though, since there's no good way to know when to unlock
it.  (I'd recommend against repeating the storage API's "unlock when the
script returns" model, which fell apart as soon as web workers entered the
picture.  Regardless of the fact that clipboard access probably won't show
up in workers any time soon, it's not a good model.)

I don't think trying to guarantee that the clipboard won't change while the
script is running is worth the trouble.

This raises another question.  What happens if a paste event occurs, but the
clipboard is locked by an external application as the script is running?
The browser can't read the clipboard data, so the getData() call will fail.
This is a very rare case, so maybe it should act as though the clipboard is
empty and follow the "data type not found" code path (eg. "not available"
rather than "not found").

-- 
Glenn Maynard