[Bug 25683] Document "unsafe to dispatch events" in D3E if it's possible

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