Bug 30639 - "Paste and Match Style" doesn't fire the dom paste event
: "Paste and Match Style" doesn't fire the dom paste event
Status: RESOLVED FIXED
Product: WebKit
Classification: Unclassified
Component: WebCore Misc.
: 528+ (Nightly build)
: All Mac OS X 10.5
: P2 Normal
Assigned To: Tony Chang
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-10-21 11:24 PDT by Tony Chang
Modified: 2010-01-11 01:21 PST (History)
8 users (show)

See Also:


Attachments
Patch v1 (2.29 KB, patch)
2009-10-21 12:19 PDT, Tony Chang
no flags Details | Formatted Diff | Diff
Patch v1 (2.60 KB, patch)
2009-10-21 12:25 PDT, Tony Chang
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Tony Chang 2009-10-21 11:24:31 PDT
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.
Comment 1 Tony Chang 2009-10-21 12:19:55 PDT
Created attachment 41598 [details]
Patch v1
Comment 2 Tony Chang 2009-10-21 12:25:56 PDT
Created attachment 41599 [details]
Patch v1
Comment 3 Darin Adler 2009-10-21 14:59:44 PDT
Comment on attachment 41599 [details]
Patch v1

In this case, how would the DHTML paste handler know that this is a plain-text paste?
Comment 4 Tony Chang 2009-10-21 15:47:12 PDT
(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?
Comment 5 Darin Adler 2009-10-21 15:51:42 PDT
(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.
Comment 6 Eric Seidel 2009-10-21 16:31:56 PDT
Isn't that what DOMTextInput events are for?
http://www.w3.org/TR/DOM-Level-3-Events/#event-type-textInput
Comment 7 Daniel Danilatos 2009-10-21 16:52:22 PDT
(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.
Comment 8 Daniel Danilatos 2009-10-21 16:54:34 PDT
(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?
Comment 9 Adam Barth 2009-11-30 12:19:42 PST
Attachment 41599 [details] passed the style-queue
Comment 10 Eric Seidel 2009-12-14 13:10:21 PST
Comment on attachment 41599 [details]
Patch v1

This makes sense to me.
Comment 11 WebKit Commit Bot 2010-01-11 01:21:08 PST
Comment on attachment 41599 [details]
Patch v1

Clearing flags on attachment: 41599

Committed r53068: <http://trac.webkit.org/changeset/53068>
Comment 12 WebKit Commit Bot 2010-01-11 01:21:20 PST
All reviewed patches have been landed.  Closing bug.