Bug 22070 - Add input/beforeinput events to D3E [was "Revive textInput"]
Add input/beforeinput events to D3E [was "Revive textInput"]
Status: RESOLVED FIXED
Product: WebAppsWG
Classification: Unclassified
Component: DOM3 Events
unspecified
PC All
: P2 normal
: ---
Assigned To: Gary Kacmarcik
public-webapps-bugzilla
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-05-17 15:58 UTC by Gary Kacmarcik
Modified: 2013-08-26 16:15 UTC (History)
7 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Gary Kacmarcik 2013-05-17 15:58:43 UTC
textInput (the replacement for keypress) was removed from the spec because
it was thought that the more general 'input' event would be a suitable
replacement. However, this is not the case.

'input' is not a valid replacement because:
* it fires after the chars have been added to the field (ie: you can't cancel the key)
* it doesn't indicate what new chars were added (only that something changed)

'beforeinput' is slightly better, but still not appropriate:
* it doesn't indicate what new chars were added (only that something changed)

Without something like textInput, browsers will still be forced to support
keypress because we will not be providing replacement functionality. Either that
or developers would need to manually track the contents of each field and compare
to see what had changed between each event (ugh!).

We need to:
1) Reinstate textInput
2) Remove all references to HTML5 'input' as a replacement for keypress
Comment 1 Anne 2013-05-17 16:03:52 UTC
The intended replacement for textInput was beforeinput. If it doesn't indicate something we should just add that.
Comment 2 Gary Kacmarcik 2013-05-17 17:15:41 UTC
Adding a text/data attribute (or something similar) to 'beforeinput' sounds good to me. We'll need this event to fire this during IME composition as well so that there's only one event that can be used to catch all keyboard input.

Where is 'beforeinput' being spec'ed?  I was unable to find a proper definition for the event.
Comment 3 Anne 2013-05-17 17:17:36 UTC
I thought the idea was to add it in this specification.
Comment 4 Ojan Vafai 2013-05-17 17:37:50 UTC
For better or worse, it's currently in https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html. The editing API spec is on hold waiting on browser vendor feedback. I'd be fine with beforeInput/input being in DOM3 Events or UI Events.

+1 to adding whatever we need to beforeInput/input instead of putting textInput back in. It was always the idea with replacing textInput with beforeInput that beforeInput could be a strict superset of functionality.

Another advantage of this approach is that the input event also gets all these new properties.
Comment 5 Gary Kacmarcik 2013-05-17 17:50:36 UTC
Ok. that sounds good to me.

I'll add a section in D3E to describe 'input' and 'beforeinput'.
Comment 6 Olli Pettay 2013-05-17 17:55:53 UTC
Could we add beforeinput to D4E/UIEvents spec and not change D3E?
(assuming we want stable D3E any time soon)
Comment 7 Gary Kacmarcik 2013-05-17 18:40:50 UTC
We need to clarify some of the keyboard and composition event examples in the D3E spec, and for them to be useful, I'd like to have them include 'beforeinput' and 'input'.

For example, in 6.2.2 (http://www.w3.org/TR/DOM-Level-3-Events/#keys-Modifiers), there are 3 examples. The first 2 generate an implicit keypress/testinput/input event, whereas the 3rd one does not. However, at a glance they all look the same since the same events are fired.

Making the beforeinput/input events explicit in these examples will make it clear what is going on and make the examples more useful.

Also note that we won't have a spec'ed replacement for keypress until we have beforeinput/input.

At the moment, it doesn't seem to me that including these events would slow anything down. In fact, the lack of a proper spec for these elements is more likely to cause confusion/delay, so it might as well be here.

Do you know of anything controversial with beforeinput/input that is likely to cause delays?
Comment 8 Olli Pettay 2013-05-17 19:01:05 UTC
input is probably "easy" to define, but beforeinput may need some
more iterations because it is not implemented in too many engines.
Comment 9 Masayuki Nakano 2013-05-17 23:43:53 UTC
First, I believe that beforeinput should be fired only before/after keypress events and before compositionend event. I.e., I don't think it should be fired before composition update event.

1. There must be a requirement that web developers want to treat only committing text (i.e., except composing text).
2. beforeinput immediately before/after compositionupdate cannot cancel the latest input in IME on any platforms AFAIK.
3. If beforeinput has "data" attribute similar to CompositionEvent, then, one event handle can handle both beforeinput and compositionupdate events. Although, I think that in such case, they should use input event.

When you add beforeinput to the spec, please define the event order of beforeinput especially with keypress, compositionend event.

Additionally, if beforeinput is fired immediately before keypress and beforeinput's default is prevented, then, browsers may stop dispatching following keypress event(s) for reducing the cost. But I think compositionend event shouldn't be so even beforeinput's default is prevented because compositioend event should be fired for compositionstart. It also indicates the term of composition.

I recommend that beforeinput should be fired immediately before first keypress event for a set of key events. Gecko implements shortcut key handling with keypress event. Therefore, firing keypress event after beforeinput is very good thing for Gecko because text input in editor should win any shortcut key handler.

And also I recommend that beforeinput should be fired immediately before compositionend event. Even beforeinput's default is prevented, compositionend's data value should NOT be empty string. I.e., it should have original committed string. E.g., web application may want to cancel the input to the focused editor, but they want to handle actual committed string in compositionend handler.

Finally, if it's possible, any web browsers shouldn't allow to input text with untrusted beforeinput events because of security risk.
Comment 10 Masayuki Nakano 2013-05-17 23:55:01 UTC
And, it might be worthwhile to add "inputDevice" attribute which indicates the beforeinput is caused by a key press or IME.

getModifierState() is also necessary? I'm not sure about this. I have no idea for such cases beforeinput event handlers need to check current modifier state.
Comment 11 Gary Kacmarcik 2013-05-18 00:58:16 UTC
(In reply to comment #9)
> First, I believe that beforeinput should be fired only before/after keypress
> events and before compositionend event. I.e., I don't think it should be
> fired before composition update event.

'keypress' events aren't defined in the spec, but other than that I wholeheartedly agree. 'beforeinput' should happen before the 'compositionend' and 'input' should fire after that.

It doesn't make sense for it to fire after composition update events.

> When you add beforeinput to the spec, please define the event order of
> beforeinput especially with keypress, compositionend event.

keypress is not going to be part of the spec. 'beforeinput' will have the information that 'textInput' was going to have, so 'beforeinput' will be the replacement for 'keypress'.
Comment 12 Gary Kacmarcik 2013-05-18 01:03:10 UTC
(In reply to comment #10)
> And, it might be worthwhile to add "inputDevice" attribute which indicates
> the beforeinput is caused by a key press or IME.

What other values would this attribute take: "Keyboard", "IME", ...
   "Voice"?
   "Other"

> getModifierState() is also necessary? I'm not sure about this. I have no
> idea for such cases beforeinput event handlers need to check current
> modifier state.

Agreed, not sure how useful it is. Does anyone know what the motivating use cases were for this? Especially since it glosses over right/left location differences and says to track keydown/keyup events manually.

There have been suggestions for a more general "get keyboard state" API. Perhaps this should be moved and made part of that discussion?
Comment 13 Masayuki Nakano 2013-05-18 01:05:51 UTC
Hmm, I strongly believe that keypress event should be included in D3E as deprecated event even without its detail because of for compatibility between web browsers. The relation between D3E recommend events and deprecated keypress event is important.
Comment 14 Masayuki Nakano 2013-05-18 01:13:04 UTC
(In reply to comment #12)
> (In reply to comment #10)
> > And, it might be worthwhile to add "inputDevice" attribute which indicates
> > the beforeinput is caused by a key press or IME.
> 
> What other values would this attribute take: "Keyboard", "IME", ...
>    "Voice"?
>    "Other"

I have no idea for other values because perhaps, voice input and handwriting system use IME framework. However, for example, if beforeinput event handlers want to handle the events caused by key event, such information is useful. Such use case *might* be possible if they want to implement shortcut key like mechanism.
Comment 15 Masayuki Nakano 2013-05-18 01:21:02 UTC
I have a question about beforeinput.

I'm not sure the textinput behavior on WebKit (and IE?), beforeinput will be caused by "paste" or other edit commands too? In other words, it should be fired immediately before any mutation in editor? If so, beforeinput event is needed to be fired from editor implementation. Then, it's difficult to implement beforeinput as cancelable event especially for the latter case. For example, edit commands might be performed from event handlers including beforeinput event handler! So, it may cause stack overflow. For preventing the stack overflow, the event should be dispatched asynchronously while a event handler is being performed.
Comment 16 Gary Kacmarcik 2013-08-26 16:15:01 UTC
We've added sections for beforeinput and input to the ED. The other issues mentioned in this bug have been called out as "issues" in the spec.