WebKit Bugzilla
If I paste into a text field using Paste and Match Style, a paste event isn't fired. It looks like Editor::pasteAsPlainText doesn't fire the dom event. In Editor::paste, the event is fired by tryDHTMLPaste. Anyway, patch coming up.
Created attachment 41598 [details] Patch v1
Created attachment 41599 [details] Patch v1
Comment on attachment 41599 [details] Patch v1 In this case, how would the DHTML paste handler know that this is a plain-text paste?
(In reply to comment #3) > (From update of attachment 41599 [details]) > In this case, how would the DHTML paste handler know that this is a plain-text > paste? You're right, the paste handler wouldn't know. To provide some context, this was requested by people working on Google Wave and other rich text editors. Normally you want to watch for paste events so you can know when to start an autosave of editable text. Not firing an event at all can cause data to not be saved at all. I suppose you could fire a different event or add a variable to the paste event so the caller can see what type of paste is happening. Neither of those sound like great solutions. I checked on Firefox on Mac, but it doesn't have a "Paste and Match Style". I'm not sure how to proceed here, maybe Hixie has some thoughts?
(In reply to comment #4) > To provide some context, this was requested by people working on Google Wave > and other rich text editors. Normally you want to watch for paste events so > you can know when to start an autosave of editable text. Are there other ways of getting new text in besides typing and paste? For example: Dragging text in, dragging text out, correcting spelling, doing other transformations such as Make Upper Case in the Transformations submenu on Mac OS X 10.6’s context menu in Safari. Does Google Wave work properly with things like that? I ask because it might be better to come up with a solution that will work for those cases as well rather than making this change. Or in addition.
Isn't that what DOMTextInput events are for? http://www.w3.org/TR/DOM-Level-3-Events/#event-type-textInput
(In reply to comment #5) > (In reply to comment #4) > > To provide some context, this was requested by people working on Google Wave > > and other rich text editors. Normally you want to watch for paste events so > > you can know when to start an autosave of editable text. > > Are there other ways of getting new text in besides typing and paste? Heaps! These are a major source of problems. There have been many discussions about this, but the main ideal is that the browser should NEVER change the DOM without giving the javascript app some kind of cancellable event. (Mutation events are a nasty, uncancellable, non-user-intent-conveying catchall). > > For example: Dragging text in, dragging text out, correcting spelling, doing > other transformations such as Make Upper Case in the Transformations submenu on > Mac OS X 10.6’s context menu in Safari. Does Google Wave work properly with > things like that? > If there are no events given, then not. Undo/Redo are also major sore points (if done via the edit menu) > I ask because it might be better to come up with a solution that will work for > those cases as well rather than making this change. Or in addition. I think it's good to fix plain text paste now one way or another, since it's so similar to paste.
(In reply to comment #6) > Isn't that what DOMTextInput events are for? > http://www.w3.org/TR/DOM-Level-3-Events/#event-type-textInput I personally don't mind what event we get - but it seems we don't get either paste or textInput for ctrl+shift+v, and we dont get textInput for regular ctrl+v either http://www.danilatos.com/event-test/ExperimentTest.html Does textInput contain any field that defines the subtype of input?
Attachment 41599 [details] passed the style-queue
Comment on attachment 41599 [details] Patch v1 This makes sense to me.
Comment on attachment 41599 [details] Patch v1 Clearing flags on attachment: 41599 Committed r53068: <http://trac.webkit.org/changeset/53068>
All reviewed patches have been landed. Closing bug.