- From: <bugzilla@jessica.w3.org>
- Date: Wed, 27 Nov 2013 23:50:36 +0000
- To: public-webapps-bugzilla@w3.org
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