Bug 30639 – "Paste and Match Style" doesn't fire the dom paste event

• Component: WebCore Misc.
• Status: RESOLVED FIXED

[Tony Chang]

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.

[Tony Chang]

Created attachment 41598 [details]
Patch v1

[Tony Chang]

Created attachment 41599 [details]
Patch v1

[Darin Adler]

Comment on attachment 41599 [details]
Patch v1

In this case, how would the DHTML paste handler know that this is a plain-text paste?

[Tony Chang]

(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?

[Darin Adler]

(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.

[Eric Seidel (no email)]

Isn't that what DOMTextInput events are for?
http://www.w3.org/TR/DOM-Level-3-Events/#event-type-textInput

[Daniel Danilatos]

(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.

[Daniel Danilatos]

(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?

[Adam Barth]

Attachment 41599 [details] passed the style-queue

[Eric Seidel (no email)]

Comment on attachment 41599 [details]
Patch v1

This makes sense to me.

[WebKit Commit Bot]

Comment on attachment 41599 [details]
Patch v1

Clearing flags on attachment: 41599

Committed r53068: <http://trac.webkit.org/changeset/53068>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.