920405 - Clipboard API does not work correctly when pasting into `window`

Status: RESOLVED DUPLICATE of bug 846674

(Core :: DOM: Events, defect)

Description

[Drew DeVault]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0 (Beta/Release)
Build ID: 20130917081302

Steps to reproduce:

http://drewdevault.com/ffdemo.html

Register with window.onpaste, with a simple handler to drop pasted text into the page.


Actual results:

No text is written to the page.


Expected results:

Each time you paste plaintext into the page, it should show the pasted text.

This works correctly in WebKit-based browsers.

Comment 1

[Justin Dolske [:Dolske]]

(From IRC)

It works when there's a focused element that will take text input (like <input>). So the bug seems specifically for when you're wanting to paste in a state where there's normally nothing to paste into.

http://dev.w3.org/2006/webapi/clipops/clipops.html#paste-event implies the event should still fire, but I'm rather curious how this is expected to work... Normally the browser (like other apps) disables the Paste menuitems and keyboard shortcuts when they're not expected to do anything (similarly for cut/copy). Not sure how this would work at all on mobile.

Comment 2

[Neil Deakin]

We don't allow pasting into a read-only document. You can make the document be in design mode or use contenteditable though to be able to paste.

The spec doesn't specify how to indicate that paste should be enabled. You could argue that it says that "the event fires regardless", but it also says that "When the user initiates a paste operation" which you cannot do.

> This works correctly in WebKit-based browsers.

It 'works' in Chrome but not in Safari or IE, so I don't think changing this is a good idea right now.

Comment 3

[Drew DeVault]

The specific use case where I learned about this problem was here: https://mediacru.sh.

You're meant to be able to paste URLs and images into the page to upload them. I'm going to have to resort to something hacky and weird to make this work if Firefox declines to support the spec this way.

Comment 4

[Drew DeVault]

Sorry to bump this again, but I was reading the spec and was reminded of this bug.

Quote from http://www.w3.org/TR/clipboard-apis/#paste-event:

>The paste event has no default action in a non-editable context, but the event fires regardless.

The event should fire even if you aren't in an editable document.

Comment 5

[Neil Deakin]

Yes, the spec says it should fire in an editable document, but the user has no means to perform a paste since the paste command is disabled, so there is nothing from which to trigger the paste event.

This is a longstanding problem that no browser has yet resolved.

Comment 6

[Drew DeVault]

As I said when I opened this bug, it works fine in Chrome. The user knows that Ctrl+V is the shortcut for pasting and when they use it, the event fires.

Comment 7

[Neil Deakin]

It doesn't work correctly in Chrome no. Chrome doesn't update its edit menu UI, or does so inconsistently. This leads to cases where menu items are enabled when nothing will happen. For example, when focusing an empty text field on a page, the Copy item is enabled, despite there being nothing to copy. (one bug I just noticed is that the copy command on the context menu is not enabled). No other application or browser operates this way.

Comment 8

[Drew DeVault]

I don't think the spec is written with the implementation in mind. The menus and when they're enabled and such is a UA problem. The spec is pretty clear on the subject of when the paste event fires.

Comment 9

[Neil Deakin]

Yes, it says that the paste event fires when "When the user initiates a paste operation". The user cannot initiate a paste operation in a non-editable document. This includes the shortcut key.

There is more discussion of this issue in bug 846674, which this bug is really a duplicate of.