Id It possible when an image (for example) is pasted from the clipboard into a webkit editable content region, and the source code looks like this:
webkit-fake-
Obviously you can use whatever abstraction for event listeners you like; I'm providing an unabstracted version; this will also exclude IE < 9
if('addEventListener' in editableElement) {
editableElement.addEventListener('paste', function(e) {
// First two conditionals should weed out browsers which
// don't allow access to pasted content
if(('clipboardData' in e) && ('types' in e.clipboardData) &&
e.clipboardData.types.indexOf('public.url') > 1) {
e.target.ownerDocument.execCommand('insertImage', null,
e.clipboardData.getData('public.url'));
e.preventDefault();
e.stopPropagation();
}
}, false);
}
When dealing with weirdness in WebKit pastes, it's a good idea to inspect the paste event's clipboardData
:
console.dir(eventObj.clipboardData);
But in my experience, Web Inspector seems to inspect the live object in memory at the time the console is displayed, rather than the object at the time and in the scope console.dir
was called. By this point, the paste
event will have ended and Javascript's access to the clipboard will have been revoked, so that the types
property will be null
and the actual clipboard data will be hidden. But in your event, you can do this to get a better idea of what types are available and what their output would be:
for(var i = 0; i < eventObj.clipboardData.types.length; i++) {
console.log(eventObj.clipboardData.types[i] + ':',
eventObj.clipboardData.getData(eventObj.clipboardData.types[i]));
}
I've spent more time than I'd like to admit debugging clipboardData
in WebKit browsers. Hope this helps!