[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 #4 from Masayuki Nakano <masayuki@d-toybox.com> ---
(In reply to Ojan Vafai from comment #3)
> (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.

I don't think that it's very hard to implement on some browsers, the spec won't
available at least for a long time. It doesn't make happy anybody.

> > > 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=aekVQXANJVQMbAx1VRllVQlNGQgFKRR5HUFAfHRCWmJqcHz1PHXKeoE1QSEhGU6UQch8DDQNLk
> ZNwD24JCKJQCAoPUE91AR4BYAkKAVytAdkBw8UIs7W3yg9oAQzRCHUdQ7gIHK1era3cxsjiV0JNVk
> bQAcejdoDLwAA=

Does it true for all cases? E.g., execCommand().

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

beforeinput is used for cancelling user input. On the other hand, input is used
for taking some reaction for user input. So, beforeinput only fired at caused
by cancellable action does makes sense even if there are some cases input event
is fired without beforeinput.

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

Received on Tuesday, 26 November 2013 00:37:54 UTC