[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 #5 from Ojan Vafai <ojan@chromium.org> ---
> > > > 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().

Ah. You're right that execCommand fires input in WebKit and Gecko. That seems
fine to me. execCommand is a weird, crazy API. It's fine for it to behave a bit
weird. The most common use of execCommand is to map it to toolbar buttons that
the user presses anyways.

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

I mostly agree with this, except I don't think the *only* use-case for
beforeinput is cancelling user input. Another use case is preparing for user
input. For example, an undo manager could save the state before the 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.

I don't agree with this conclusion. Partially because I think there are other
use cases than cancelling the user input and partially because I think it's
just confusing to developers.

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

Received on Tuesday, 26 November 2013 01:30:56 UTC