[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

Travis Leithead [MSFT] <travil@microsoft.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |travil@microsoft.com

--- Comment #19 from Travis Leithead [MSFT] <travil@microsoft.com> ---
So, I've lost track of what we want to do with this bug.

Our spec text, as currently stands, is very light on details. Of beforeinput,
relative to the comments in the bug it says:

  ["Input events are sent as notifications whenever the DOM is being updated"]

A generalization: may not be strictly true if beforeinput/input are not
dispatched when the DOM was modified by script.

  ["The input events defined in this specification MUST occur in a set order
relative to one another."]

A generalization: basically true.

  ["A user agent MUST dispatch this event [beforeinput] when the DOM is about
to be updated."]

May need to refine this text to explain the conditions under which is may not
be dispatched or may be delayed, depending on what we do with Bug 25683.

  ["A user agent MUST dispatch this event [input] immediately after the DOM has
been updated"]

Again, may need to clarify the conditions based on reality in user agents
today.

Finally, as Gary noted above, we have 5.2.7.6, which talks about the order of
events in relation to compositionupdate and compositionend.

  ["Most IMEs do not support canceling updates during a composition session."]

Does the above also mean that beforeinput isn't cancelable? I think it does.

  ["... In this case, canceling the beforeinput event will have no effect"]

This also seems to indicate that when an IME is in control the user agent may
not have an opportunity to cancel the DOM updates, meaning that beforeinput can
only be useful as a pre-change notification and not cancelable.

Is it still worth it to ask user agents to dispatch beforeinput in those last
two cases (where they can't reasonably stop the IME's input)? If so, then
beforeinput seems totally redundant with compositionupdate and compositionend
at least in this scenario. I understand wanting to use beforeinput as a general
catch all for user-input (including IME) and so perhaps it is OK to redundantly
dispatch it, but we'll need to have a short section defining what it means to
dispatch a non-cancelable beforeinput event. E.g., the cancelable attribute
will be set to false, etc.

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

Received on Friday, 23 May 2014 22:57:51 UTC