WebKit Bugzilla
You need to log in before you can comment on or make changes to this bug.
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 an attachment (id=41598) [details] Patch v1
Created an attachment (id=41599) [details] Patch v1
(From update of attachment 41599 [details]) 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] [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
(From update of attachment 41599 [details]) This makes sense to me.
(From update of attachment 41599 [details]) Clearing flags on attachment: 41599 Committed r53068: <http://trac.webkit.org/changeset/53068>
All reviewed patches have been landed. Closing bug.