Closed Bug 280683 Opened 16 years ago Closed 13 years ago

Implement onpaste for text controls

Categories

(Core :: DOM: Events, enhancement)

x86
Windows XP
enhancement
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: bfults, Unassigned)

References

Details

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.
Why? What's the use case?
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.
Wouldn't you also want to clean it if it was typed in?
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.
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.
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
Blocks: 278272
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.
onpaste is the ideal solution.  However an option to disable formatting in paste
events would solve alot of our problems as well.
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.
(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.
Isn't this handles in bug 280959?
Looks like it to me. Fixed by bug 280959 (and not backed out by bug 418457).
Status: NEW → RESOLVED
Closed: 13 years ago
Depends on: 280959
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.