[Bug 23913] beforeinput should be fired only when the DOM change is caused by direct input by keypress or composition

https://www.w3.org/Bugs/Public/show_bug.cgi?id=23913

--- Comment #3 from Ojan Vafai <ojan@chromium.org> ---
(In reply to Masayuki Nakano from comment #2)
> (In reply to Ojan Vafai from comment #1)
> > I think you can generalize to firing beforeinput only for user-actions, not
> > script. I can think of other user actions that you'd want beforeinput to
> > fire for than just key input (e.g. cut/paste from a menu). 
> 
> I don't want to fire beforeinput at cut/paste.

Why?

> As I said, it can be
> performed from JS. Additionally, Gecko cannot distinguish if the editing
> action is performed from JS or user action. If it should be fired only when
> user executes it, we need for several years for implementing this feature.

That seems like a bug Gecko needs to fix. Doesn't make sense to define the
standard around a Gecko bug.

> > This is already how the input event works, so having beforeinput match that
> > makes sense.
> 
> At least on Gecko, input event is fired when the editor value is changed
> always.

In this simple test case, that doesn't seem to be the case:
http://plexode.com/eval3/#s=aekVQXANJVQMbAx1VRllVQlNGQgFKRR5HUFAfHRCWmJqcHz1PHXKeoE1QSEhGU6UQch8DDQNLkZNwD24JCKJQCAoPUE91AR4BYAkKAVytAdkBw8UIs7W3yg9oAQzRCHUdQ7gIHK1era3cxsjiV0JNVkbQAcejdoDLwAA=

> The important difference between beforeinput and input is, beforeinput is
> cancellable. I.e., it MUST be fired before modifying editor value. This
> means that beforeinput may be nested if beforeinput handler causes another
> beforeinput. (input event isn't cancellable, therefore, browser can wait
> safe time to dispatch input event.)

I don't think it makes sense for beforeinput and input to fire for a different
set of actions.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Tuesday, 26 November 2013 00:19:04 UTC