January 17, 2012

The Paste Wasteland

Or, “Why the onPaste event is a mess.”

When you work on the bleeding-edge, sometimes you’re going to get cut. The tech isn’t stable, things are buggy and may not conform to [a/the] standard—but the onPaste event isn’t a bleeding-edge technology. In fact, it’s been around since IE5. So why is it such a mess?

I spent a lot of time working with the paste event, recently, as I’ve been working on Hopper. What I found was a stunning lack of uniformity. Every single browser seems to have it’s own implementation of the event (and all of them aren’t great). I wanted to go over a few of the implementations and give you an idea of just what sort of things to look out for when using this non-standard event.

The simplest and most complete implementation is Google Chrome’s (all examples assume we’re using jQuery, to reduce verbosity):

Whoa. And the above isn’t even comprehensive; I’m still finding plenty of edge cases that return non-plain-text results when we want the plain text.

Firefox, on the other hand, has a thoroughly disappointing implementation. You cannot retrieve the pasted content from the event, and—unlike Chrome, where you can bind to anything—the event only seems to work when bound to a field that would “normally” accept a paste event, like an input field or textarea.

You’ll notice that we use a timer and repeatedly attempt to get the textarea’s content. This is because the paste event doesn’t seem to fire in sync with the content actually appearing in the textarea and it may take a couple of attempts until this becomes the case.

What about IE?

Pretty basic. Around since IE5. Not very versatile. But at least we can get the data.

And last but not least, Safari, which has the strangest implementation of all:

This isn’t to even mention the differences between OSes (OS X and Windows) and how they each handle metadata in paste content.

So how do we reconcile all of this information and variety of implementations? It seems the safest solution is to have an off-screen, or hidden, text field that you can put the user’s focus into, as necessary, and bind all of your paste events accordingly. Then, combine the above outlined methods (I’ll leave as an exercise to the reader to combine all of them into a cross-browser implementation).

You’ll also need to test a variety of paste cases—items pasted from Word, the browser, and other rich text editors all react differently and may return different metadata/markup.

The greatest thing is that we can capture paste content from users and find new, creative ways to improve user experience. The worst part is the countless implementations of the paste event and the data it returns.

Update Jan 25, 2011: I was informed recently by web developer Joel Besada that, despite the lack of the clipboardData object in Firefox, you can still retrieve images from the clipboard. Thanks Joel! I found that a variation of this technique also works in IE, interestingly enough.

You should follow me on Twitter @endtwist.

You should follow me on Twitter here.

Joshua Gross is web designer and developer, and principal of Planetary based in Brooklyn, NY.