Bug 75891 – Safari fails to fire paste events

• Component: HTML Editing
• Status: NEW

[Mark Kristensson]

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.

[Alexander Ljungberg]

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.

[Alexander Ljungberg]

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.

[Daniel Böhringer]

i can confirm that the issue is still present in Safari 7.0.2. Works in Chrome/FF.

[Sorin Sbarnea]

And more important, why is this still unconfirmed?

[Daniel Böhringer]

i herewith confirm that this bug is still present in safari 7.0.5.

[Andrew Hankinson]

This bug should be re-classified to Macintosh Mac OS X 10.9+ and Safari 9537.77.4

[Daniel Böhringer]

still an issue in Version 7.0.6 (9537.78.2)

[Daniel Böhringer]

still an issue on safari 8

[Martin Carlberg]

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...

[Alexandre Wilhelm]

Any news of this issue ? We would like to support safari for our application, but this is impossible because this issue...

[Alexey Alexandrov]

The issue seems to exist in Safari 9 too.

[Nicholas Kyriakides]

+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

[Eduard Kyvenko]

Doesn't work in Safari 9.1, El Capitan
contentEditable property helps as a workaround

[Lucas Forschler]

Mass move bugs into the DOM component.

[Radar WebKit Bug Importer]

<rdar://problem/49839995>

[Ryosuke Niwa]

Maybe this has been fixed by https://github.com/WebKit/WebKit/pull/38127?