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