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
: WebKit
WebCore Misc.
: 528+ (Nightly build)
: All Mac OS X 10.5
: P2 Normal
Assigned To:
:
:
:
:
  Show dependency treegraph
 
Reported: 2009-10-21 11:24 PST by
Modified: 2010-01-11 01:21 PST (History)


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


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2009-10-21 11:24:31 PST
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 From 2009-10-21 12:19:55 PST -------
Created an attachment (id=41598) [details]
Patch v1
------- Comment #2 From 2009-10-21 12:25:56 PST -------
Created an attachment (id=41599) [details]
Patch v1
------- Comment #3 From 2009-10-21 14:59:44 PST -------
(From update of attachment 41599 [details])
In this case, how would the DHTML paste handler know that this is a plain-text paste?
------- Comment #4 From 2009-10-21 15:47:12 PST -------
(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?
------- Comment #5 From 2009-10-21 15:51:42 PST -------
(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 From 2009-10-21 16:31:56 PST -------
Isn't that what DOMTextInput events are for?
http://www.w3.org/TR/DOM-Level-3-Events/#event-type-textInput
------- Comment #7 From 2009-10-21 16:52:22 PST -------
(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 From 2009-10-21 16:54:34 PST -------
(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 From 2009-11-30 12:19:42 PST -------
Attachment 41599 [details] passed the style-queue
------- Comment #10 From 2009-12-14 13:10:21 PST -------
(From update of attachment 41599 [details])
This makes sense to me.
------- Comment #11 From 2010-01-11 01:21:08 PST -------
(From update of attachment 41599 [details])
Clearing flags on attachment: 41599

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