Bug 75891 - Safari fails to fire paste events
Summary: Safari fails to fire paste events
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: DOM (show other bugs)
Version: 525.x (Safari 3.2)
Hardware: All All
: P2 Normal
Assignee: Nobody
Keywords: InRadar
Depends on:
Reported: 2012-01-09 14:37 PST by Mark Kristensson
Modified: 2019-04-11 21:26 PDT (History)
16 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Mark Kristensson 2012-01-09 14:37:05 PST
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.
Comment 1 Alexander Ljungberg 2013-06-13 16:00:39 PDT
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.
Comment 2 Alexander Ljungberg 2013-06-13 17:18:25 PDT
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)
    return frame->editor().canPaste();

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.
Comment 3 Daniel Böhringer 2014-05-06 01:34:33 PDT
i can confirm that the issue is still present in Safari 7.0.2. Works in Chrome/FF.
Comment 4 Sorin Sbarnea 2014-05-15 02:49:40 PDT
And more important, why is this still unconfirmed?
Comment 5 Daniel Böhringer 2014-07-13 22:52:12 PDT
i herewith confirm that this bug is still present in safari 7.0.5.
Comment 6 Andrew Hankinson 2014-07-14 02:09:15 PDT
This bug should be re-classified to Macintosh Mac OS X 10.9+ and Safari 9537.77.4
Comment 7 Daniel Böhringer 2014-08-24 23:44:58 PDT
still an issue in Version 7.0.6 (9537.78.2)
Comment 8 Daniel Böhringer 2014-10-17 00:09:09 PDT
still an issue on safari 8
Comment 9 Martin Carlberg 2014-10-17 15:13:01 PDT
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...
Comment 10 Alexandre Wilhelm 2014-10-22 16:17:29 PDT
Any news of this issue ? We would like to support safari for our application, but this is impossible because this issue...
Comment 11 Alexey Alexandrov 2015-10-15 22:44:37 PDT
The issue seems to exist in Safari 9 too.
Comment 12 Nicholas Kyriakides 2015-12-05 20:03:38 PST
+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
Comment 13 Eduard Kyvenko 2016-06-08 07:54:56 PDT
Doesn't work in Safari 9.1, El Capitan
contentEditable property helps as a workaround
Comment 14 Lucas Forschler 2019-02-06 09:18:38 PST
Mass move bugs into the DOM component.
Comment 15 Radar WebKit Bug Importer 2019-04-11 21:26:49 PDT