280683 - Implement onpaste for text controls

Status: RESOLVED FIXED

(Core :: DOM: Events, enhancement)

Description

[Brad Fults]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

See: http://msdn.microsoft.com/workshop/author/dhtml/reference/events/onpaste.asp

Reproducible: Always

Steps to Reproduce:

Actual Results:  
There is no onpaste event.

Expected Results:  
There should be an onpaste event.

Comment 1

[Hixie (not reading bugmail)]

Why? What's the use case?

Comment 2

[Anne (:annevk)]

I guess you can use this to catch the data that is going to be pasted and clean
it (for example the HTML) before you actually put it in.

Comment 3

[Hixie (not reading bugmail)]

Wouldn't you also want to clean it if it was typed in?

Comment 4

[Anne (:annevk)]

Think of contentEditable or designMode in Mozilla where someone pastes a large
piece of junk straight from Word. Word uses all kinds of markup you do not want
in your WYSIWYG editor so when someone enters that you want to clean it first.

Comment 5

[leon1024]

This is essential to making editMode work properly.
There can be no security concerns: the user chose to paste the data.

There's no need to mimic M$, just give us some way to access the data that is to
be pasted.

Comment 6

[Csaba Gabor]

I think there 's a huge interest in knowing when a DOM element has changed.  
For example, there's much utility in knowing when a text element has had its
input changed.
Scenario A:  The irfanview case.  If you want to resize an image in IrfanView,
then when you put in a different x dimension (and have the aspect ratio marked
as 'fixed') you see the y dimension change right away and you know what you're
getting.  No wasted keystrokes
Scenario B:  It turns out that CSS isn't perfectly implemented and this may
sometimes be compensated for in javascript.  Sometimes the amount or value of
text in an input cell may be what should kick off one of these reformatting events.

It's a natural thing to want to react to changes (AS THEY HAPPEN) to objects
that we are relying on.  I think .onPaste doesn't go far enough (but if you're
going to implement it, please remember to account for pastes from the context
menu, ctrl+V, and mouse or keyboard activation of the Edit/Paste menu) and have
suggested a more generic and powerful mechanism, onPropertyChange, at
https://bugzilla.mozilla.org/show_bug.cgi?id=285272

Csaba Gabor from Vienna

Comment 7

[Zook Valem]

Depending on the definition of the "onpaste" event.  The "onpaste" event is
disabled in Gecko browsers due to security reason as stated on the comment at
http://www.telerik.com/Default.aspx?PageId=2202&b119Y=tqsX , as to prevent the
executable script from occuring.  But I could not find the documentation at
mozilla.org about the use of "onpaste" event.

Comment 8

[Giscard Girard]

onpaste is the ideal solution.  However an option to disable formatting in paste
events would solve alot of our problems as well.

Comment 9

[Anthon Pang]

Proposal?  Convert cut/copy/paste operations from other contexts (i.e., menus) to the equivalent keypress events, and make a copy of the clipboard data accessible through a keypress event property.  One advantage is that all cut/copy/paste operations can filter through a single onkeypress handler.

Comment 10

[Brad Fults]

(In reply to comment #5)
]> There's no need to mimic M$, just give us some way to access the data that is to
> be pasted.

I strongly disagree. If there is an already established working model that suits all (or an acceptable number) of use cases, creating an entirely different model just for the sake of being different is nonsensical and potentially disastrous.

Keep the anti-Microsoft-for-the-sake-of-being-anti-Microsoft stuff away from decisions that matter, please.

Comment 11

[Martijn Wargers (dead)]

Isn't this handles in bug 280959?

Comment 12

[:Gavin Sharp [email: [e-mail]]]

Looks like it to me. Fixed by bug 280959 (and not backed out by bug 418457).