- From: <bugzilla@jessica.w3.org>
- Date: Sun, 25 May 2014 03:05:52 +0000
- To: public-webapps-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25683 --- Comment #5 from Masayuki Nakano <masayuki@d-toybox.com> --- (In reply to Travis Leithead [MSFT] from comment #4) > 1. If target of the beforeinput event is beforeinput-locked, then abort; If browsers do so, it could break compatibility with some browsers which don't support "beforeinput" since such browsers don't need to check it and may allow text input at that time. > If we allow execCommand to generate beforeinput, then the following scenario > could occur: > > 1. User Types "A" into input box "input" > 2. (keydown event dispatched at "input" and is not cancelled) > 3. beforeinput event dispatched at "input" > 3.1. Event handler for beforeinput event invoked > 3.2. Event handler calls execCommand("insertText", .. "B") (on "input") > 3.3. (see below) > 3.4. Event handler cancels the beforeinput event > > In conclusion, the "input" has a value of "B". > > In step 3.3., the beforeinput event might have been dispatched, but the > "beforeinput-locked" flag prevents it from firing. This is actually good > because this was a script-initiated insertion (synchronously performed) > which the developer would otherwise need to ignore in a recursively-invoked > beforeinput event handler anyway. A similar situation would arise if the > "input" target's value attribute was modified in the handler (assuming that > beforeinput fired for script-initiated changes too--which I don't think we > want to enable). I can't think of how to force a copy/paste operation > (outside of execCommand) that is synchronous, but if it can be done, this > algorithm protects that too. This sound good. > > Also note: the algorithm only locks one element at a time, so it's possible > to have "input transfer" scenarios, where your beforeinput handler catches > the input in order to redirect it into another input box or contenteditable. Did you mean that "beforeinput-locked" is document or window wide state? -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Sunday, 25 May 2014 03:05:54 UTC