Closed Bug 280683 Opened 16 years ago Closed 13 years ago
Implement onpaste for text controls
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.
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.