[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 #7 from Ojan Vafai <ojan@chromium.org> ---
(In reply to Masayuki Nakano from comment #6)
> (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.

The point is the timing of the event. The event's properties are not used at
all. It's a timing that fires *before* any user-initiated modification and lets
you do whatever appropriate action you need to before the DOM is modified.

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

How is it a security issue? How's it different from focus/blur events? You can
get into the same sort of infinite loop with focus/blur events.

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

Received on Wednesday, 27 November 2013 21:33:08 UTC