- From: Hallvord R. M. Steen <hallvord@opera.com>
- Date: Wed, 18 May 2011 14:07:53 +0900
- To: "Daniel Cheng" <dcheng@chromium.org>
- Cc: public-webapps@w3.org
On Wed, 18 May 2011 08:14:42 +0900, Daniel Cheng <dcheng@chromium.org>
wrote:
>> Interesting. What, in your view, should the implementation do if it
>> discovers the contents has changed while a paste event thread is
>> running?
> Safari returns an empty string from getData() if this happens. If the
> caller
> is using event.clipboardData.items, maybe throw a DOM exception when
> getAs*() is called.
We have a problem indeed if we neither want to copy the data from the
clipboard nor lock it while the script is processing the paste event: If
we give the script a nicely prepared DataTransferItems list and the stuff
we've promised is no longer on the clipboard when the script tries to use
it, because another application overwrote it..
Should our implementation work harder to keep what we promise in
clipboardData.items, or should we be content that such timing issues will
be so rare that throwing is fine? After all, most applications manipulate
the clipboard only in response to user input, which is a pretty modal
source of events, and by definition the paste event will fire in response
to user input within the document..
Also, I'm not sure if we should process any HTML data on the clipboard
(including possibly adding images and embedded content to
clipboardData.items) before firing the paste event, or do so only if the
script calls getData('text/html') within the paste event thread.
Implementor feedback welcome!
--
Hallvord R. M. Steen, Core Tester, Opera Software
http://www.opera.com http://my.opera.com/hallvors/
Received on Wednesday, 18 May 2011 05:08:31 UTC