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

I don't think so. The data attribute is too cheap for creating their own undo
manager. Especially, removing selected text or a character before/after the
caret.

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

Then, how do you solve the security issue which is, beforeinput handler can
cause another beforeinput?

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

Received on Tuesday, 26 November 2013 04:54:41 UTC