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

focus, focusin, focusout and blur are non-cancelable events. Therefore, web
browser can delay to dispatch the events until previous event dispatching
finishes. Actually, Gecko does this for focus, blur and input.

However, beforeinput is cancelable. Therefore, browser cannot delay to dispatch
it.

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

Received on Wednesday, 27 November 2013 23:50:38 UTC