Safari fails to fire paste events (onpaste, onbeforepaste) attached to the document (or body) when Cmd-V is pressed and the focus is not in a text input or text area node. Prior to Lion, the onBeforePaste event fired allowing us to execute JS that put the focus into a (hidden) textarea when then accepted the paste.
I can confirm this is still a problem in Safari 6.0.4 running in Mac OS X 10.8 (Mountain Lion). The "beforepaste" handler does not fire:
- when Cmd-V is pressed
- or when the Edit menu is opened
- regardless of if it's attached to the window or document
- with or without the "capture" flag set for addEventListener
- with or without spelling the handler "beforepaste" or "onbeforepaste" (as a long fixed Safari bug required).
- nor if "beforepaste" is attached to every dom element in the whole document
This makes it seem pretty much impossible to paste into anything but a textfield or a textarea in Safari. In Cappuccino, we often have non-traditional editable controls (token fields, collection views, tables) where you'd expect to be able to paste.
The problem seems to exist in the Webkit Nightly build too (WebKit r151570).
Speaking without any experience on the WebKit source code, this code in EditorCommand.cpp:1277 looks a bit suspicious:
static bool enabledPaste(Frame* frame, Event*, EditorCommandSource)
Compare that to the same file, line 1234:
static bool enabledCopy(Frame* frame, Event*, EditorCommandSource)
return frame->editor().canDHTMLCopy() || frame->editor().canCopy();
enabledCut works similarly. So at least in this instance, paste seems to be treated differently than cut and copy, and canDHTMLPaste() is never consulted.
i can confirm that the issue is still present in Safari 7.0.2. Works in Chrome/FF.
And more important, why is this still unconfirmed?
i herewith confirm that this bug is still present in safari 7.0.5.
This bug should be re-classified to Macintosh Mac OS X 10.9+ and Safari 9537.77.4
still an issue in Version 7.0.6 (9537.78.2)
still an issue on safari 8
This is a very annoying bug. We have hundreds of users on our webapp and we have to recommend them to use another browser. Very sad...
Any news of this issue ? We would like to support safari for our application, but this is impossible because this issue...
The issue seems to exist in Safari 9 too.
+1 - If this is not fixed, we need to use a contenteditable div to catch the paste even t which makes everything more complicated when interacting with the document
Doesn't work in Safari 9.1, El Capitan
contentEditable property helps as a workaround
Mass move bugs into the DOM component.