Re: [Clipboard] checking if implementation allows reading/writing a given type to the OS clipboard

Siterer Paul Libbrecht <>:

>> Hm.. you mean a page should be able to say "Hello web browser, I   
>> just luuuuve processing application/pdf data from the clipboard" ?   
>> I don't see the use case for that. If I'm misunderstanding you   
>> please clarify :-)
> It means that if pdf is in the clipboard the paste command can stop   
> being greyed out!

Aha. I keep forgetting the UI part of this, thanks for the reminder  
and clarification ;-)

I think that the best way to address this is to spec the  
before(cut|copy|paste) events, let them be real ClipboardEvents (no  
idea what interface they use in IE and Chrome at the moment but I  
think they are so rarely used we can rework them a little) and say  
that clipboardData.types should be populated according to real  
supported types on clipboard in the beforepaste event. Hence, a page  
that can handle PDF data being pasted can listen for beforepaste and  
check if event.clipboardData.types contains application/pdf.

(Just my preliminary thoughts, nothing about before* events is spec'ed  
yet and actually I don't think they are an elegant solution. Perhaps a  
clipboardchange event would be more elegant? Clipboard change listener  
could do:


Or something like that? We could also define  
DataTransfer.enableUI('copy')) to be called at any time without any  
event listener workarounds..)

> Similarly, shouldn't something such as
>> if(event.clipboardData.isTypeSupported('foo/bar')) ...
> be callable before the event is triggered?

That was my intention originally, but I'm also worried about  
fingerprinting potential when letting scripts access new data about an  
end user's config. Hence, I'm now intending to limit it to being  
called inside event listeners like the other DataTransfer methods. I  
also think that if the event is synthetic the method should not reveal  
actual config details.


Received on Sunday, 19 February 2012 22:29:10 UTC