Last Comment Bug 622245 - Implement DOM3 textinput event
: Implement DOM3 textinput event
Status: RESOLVED INVALID
[parity-safari][parity-chrome]
: dev-doc-complete
Product: Core
Classification: Components
Component: DOM: Events (show other bugs)
: Trunk
: All All
: -- normal with 2 votes (vote)
: ---
Assigned To: Masayuki Nakano [:masayuki] (Mozilla Japan) (working slowly due to injured)
:
Mentors:
Depends on: 543789 698949
Blocks: 676259 501496
  Show dependency treegraph
 
Reported: 2010-12-31 01:13 PST by Masayuki Nakano [:masayuki] (Mozilla Japan) (working slowly due to injured)
Modified: 2014-08-21 05:33 PDT (History)
28 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Patch part.1 Implement DOM3 textinput event (43.07 KB, patch)
2011-09-28 00:25 PDT, Masayuki Nakano [:masayuki] (Mozilla Japan) (working slowly due to injured)
no flags Details | Diff | Review
testcase (4.65 KB, text/html)
2011-09-28 21:42 PDT, Masayuki Nakano [:masayuki] (Mozilla Japan) (working slowly due to injured)
no flags Details
testcase (+contenteditable and +textInput for WebKit) (4.84 KB, text/html)
2011-09-29 00:40 PDT, Masayuki Nakano [:masayuki] (Mozilla Japan) (working slowly due to injured)
no flags Details
testcase (5.96 KB, text/html)
2011-10-31 21:57 PDT, Masayuki Nakano [:masayuki] (Mozilla Japan) (working slowly due to injured)
no flags Details
testcase (6.62 KB, text/html)
2011-10-31 22:02 PDT, Masayuki Nakano [:masayuki] (Mozilla Japan) (working slowly due to injured)
no flags Details
Patch part.1 Implement DOM3 textinput event (40.61 KB, patch)
2011-11-01 00:21 PDT, Masayuki Nakano [:masayuki] (Mozilla Japan) (working slowly due to injured)
no flags Details | Diff | Review
Patch part.2 Implement textinput handler of editor (14.30 KB, patch)
2011-11-01 00:23 PDT, Masayuki Nakano [:masayuki] (Mozilla Japan) (working slowly due to injured)
no flags Details | Diff | Review
Patch part.3 Editor should refuse untrusted keypress event (10.21 KB, patch)
2011-11-01 00:23 PDT, Masayuki Nakano [:masayuki] (Mozilla Japan) (working slowly due to injured)
no flags Details | Diff | Review
testcase (8.10 KB, text/html)
2012-01-13 04:34 PST, Masayuki Nakano [:masayuki] (Mozilla Japan) (working slowly due to injured)
no flags Details

Description Masayuki Nakano [:masayuki] (Mozilla Japan) (working slowly due to injured) 2010-12-31 01:13:24 PST
Spinning off from bug 543789 because DOM3 textinput event needs some change which are not related to composition.
Comment 1 Jeff Muizelaar [:jrmuizel] 2011-01-19 18:08:21 PST
Seems like this implementing this would remove the need for a hidden textarea in ACE (http://mozillalabs.com/skywriter/2011/01/18/mozilla-skywriter-has-been-merged-into-ace/)
Comment 2 Masayuki Nakano [:masayuki] (Mozilla Japan) (working slowly due to injured) 2011-09-22 00:39:53 PDT
I should remove following hacky composition by replacing with textinput event.
http://mxr.mozilla.org/mozilla-central/source/widget/src/cocoa/TextInputHandler.mm#1333
http://mxr.mozilla.org/mozilla-central/source/widget/src/windows/nsTextStore.cpp#1243
Comment 3 Masayuki Nakano [:masayuki] (Mozilla Japan) (working slowly due to injured) 2011-09-28 00:25:11 PDT
Created attachment 562995 [details] [diff] [review]
Patch part.1 Implement DOM3 textinput event

I'll create other patches to implement dispatchers...
Comment 4 Masayuki Nakano [:masayuki] (Mozilla Japan) (working slowly due to injured) 2011-09-28 21:42:55 PDT
Created attachment 563297 [details]
testcase
Comment 5 Masayuki Nakano [:masayuki] (Mozilla Japan) (working slowly due to injured) 2011-09-29 00:40:08 PDT
Created attachment 563326 [details]
testcase (+contenteditable and +textInput for WebKit)
Comment 6 Masayuki Nakano [:masayuki] (Mozilla Japan) (working slowly due to injured) 2011-10-28 01:06:29 PDT
Hmm, if we would dispatch a textinput event from editor directly when it receives an input event, editor would make nested events. Especially, this makes problems when editor doesn't use system group event handler or the event is dispatched by content script.

For making simple code, I think that we should stop accepting untrusted key events in editor. It is impossible on other browsers to input text by dispatching untrusted key events, so, we don't need to keep it.

And also, when editor wants to change its content, editor should register a textinput event to PresShell (PostEvent() is good name?). And PresShell should dispatch the event before calling nsEventStateManager::PostHandleEvent().

Then, editor should modify its text only from the textinput handler.

Smaug, do you agree with this idea?

Additionally, I think that current delayed focus/blur event should use this approach too.
Type a character in the following <input>:
> data:text/html,<input onkeypress="event.target.blur();">
You can input a character *before* it loose focus. This is different behavior with WebKit, and I think that WebKit's behavior is better.
Comment 7 Masayuki Nakano [:masayuki] (Mozilla Japan) (working slowly due to injured) 2011-10-30 20:26:10 PDT
> And also, when editor wants to change its content, editor should register a textinput event to PresShell (PostEvent() is good name?). And PresShell should dispatch the event before calling nsEventStateManager::PostHandleEvent().

It seems that nsContentUtils::AddScriptRunner() may be useful.
Comment 8 Olli Pettay [:smaug] 2011-10-31 06:13:13 PDT
rniwa, do you know the reason for webkit's rather strange behavior. Is it just a bug?
Why does webkit support untrusted events at all in this case?

If untrusted events should be supported, focus handling shouldn't change the handling.
Comment 9 Ryosuke Niwa 2011-10-31 06:57:17 PDT
I'm a bit confused here looking at the comments #6 through #8. What exactly is the "strange behavior"?
Comment 10 Olli Pettay [:smaug] 2011-10-31 07:17:34 PDT
Oh, sorry, this bug is missing some context.

(in Webkit) Looks like if you dispatch untrusted textinput to some element inside contenteditable,
the text is added to the focused element, not to the element to which the event was dispatched.
That makes no sense from API point of view and is very unexpected to web devs: dispatch
event to element A, but actually element B gets modified.
<body contenteditable><span id="A">aaaaaaaaa</span><span id="B">bbbbbb[focus]bbbbbb</span></body>
or even
<body><div id="A" contenteditable></div><div id="B" contentediable>[focused]</div></body>

Masayuki, please correct me if I posted wrong examples.

Because it is very much unclear how untrusted textinput event should work in contenteditable, 
I propose implementations shouldn't have any default handling for untrusted textinput in any case.
At least not before its handling is specified properly.
Comment 11 Ryosuke Niwa 2011-10-31 07:56:18 PDT
(In reply to Olli Pettay [:smaug] from comment #10)
> (in Webkit) Looks like if you dispatch untrusted textinput to some element
> inside contenteditable,
> the text is added to the focused element, not to the element to which the
> event was dispatched.

Right, it's probably because we're triggering regular editing code to input text.

> Because it is very much unclear how untrusted textinput event should work in
> contenteditable, 
> I propose implementations shouldn't have any default handling for untrusted
> textinput in any case.
> At least not before its handling is specified properly.

The problem is that WebKit has not and doesn't support Keyboard event properly, and some websites may have replied on textInput event to emulate text input by users.
Comment 12 Olli Pettay [:smaug] 2011-10-31 14:37:11 PDT
Webkit's behavior is so strange that I propose that we don't copy it, unless really needed.
Also, we should get this all spec'ed somewhere... whatever defines contentEditable.

So, by default we shouldn't allow untrusted events to trigger default handling.
Comment 13 Masayuki Nakano [:masayuki] (Mozilla Japan) (working slowly due to injured) 2011-10-31 21:23:29 PDT
Hmm, about for untrusted keypress event, it was implemented intentionally at bug 303713. Can we kill the untrusted keypress event handling??
Comment 14 Masayuki Nakano [:masayuki] (Mozilla Japan) (working slowly due to injured) 2011-10-31 21:24:43 PDT
bz, neil: see comment 13.
Comment 15 Boris Zbarsky [:bz] 2011-10-31 21:29:15 PDT
That bug allowed untrusted keypress to work because there were pages depending on it and it had worked for years.

Does it work in other browsers?
Comment 16 Masayuki Nakano [:masayuki] (Mozilla Japan) (working slowly due to injured) 2011-10-31 21:57:20 PDT
Created attachment 570930 [details]
testcase

(In reply to Boris Zbarsky (:bz) from comment #15)
> Does it work in other browsers?

I cannot input characters by this testcase on Canary, IE9 and Opera 11.51.
Comment 17 Masayuki Nakano [:masayuki] (Mozilla Japan) (working slowly due to injured) 2011-10-31 22:02:52 PDT
Created attachment 570931 [details]
testcase

fix some nits.

Google Chrome accepts untrusted textInput event. However, other browsers refuse all untrusted events.
Comment 18 Boris Zbarsky [:bz] 2011-11-01 00:00:55 PDT
OK.  Probably ok to nix the untrusted stuff, then, as long as the spec says the right things in the process.
Comment 19 Masayuki Nakano [:masayuki] (Mozilla Japan) (working slowly due to injured) 2011-11-01 00:21:55 PDT
Created attachment 570935 [details] [diff] [review]
Patch part.1 Implement DOM3 textinput event
Comment 20 Masayuki Nakano [:masayuki] (Mozilla Japan) (working slowly due to injured) 2011-11-01 00:23:13 PDT
Created attachment 570936 [details] [diff] [review]
Patch part.2 Implement textinput handler of editor
Comment 21 Masayuki Nakano [:masayuki] (Mozilla Japan) (working slowly due to injured) 2011-11-01 00:23:49 PDT
Created attachment 570937 [details] [diff] [review]
Patch part.3 Editor should refuse untrusted keypress event
Comment 22 Olli Pettay [:smaug] 2011-11-01 04:00:38 PDT
We should probably remove support for untrusted keypress, but that is a separate bug.
And we should warn about that change first in one release and remove it in the next one.
Comment 23 Masayuki Nakano [:masayuki] (Mozilla Japan) (working slowly due to injured) 2011-11-01 06:49:54 PDT
Hmm, but as I said, implementing textinput event may cause new failures due to async modification. We need to kill it first...
Comment 24 Ojan Vafai 2011-11-02 12:05:20 PDT
Are you sure you want to implement textInput? My goal is to phase it out of WebKit. I'm not sure how realistic that is given compat concerns, but I'd like to try (we'd possibly end up aliasing textInput to beforeInput...see below).

What I would really like to see is that we implement a beforeInput event that matches the existing input event. For inputs that generate text data (e.g. where we would have fired a textInput), we put a "data" property on the beforeInput event with the text being inserted.

This makes it strictly a superset of textInput, meets more use-cases (e.g. you can detect deletes as well) and keeps the platform simpler by matching the existing input event. Getting just the text inserting events is simply an if-check on the beforeInput event.

There has already been much discussion on www-dom about this and it was shot-down not for technical objections but because it was considered too big of a change for a spec that is trying to get to CR status as soon as possible.

Even if WebKit can't kill the event due to compat issues, we'll certainly never implement most of the inputMethods (e.g. handwriting).
Comment 25 Olli Pettay [:smaug] 2011-11-02 12:44:46 PDT
textinput is a useful event and it can often be used instead of key and composition events.
(input event is just a dummy notification event which happens after the 'input' has happened.)
Using both input + textinput you can easily detect additions and deletions after they have actually
happened - which is often desired.


The supported inputMethods depends ofc the context where browser runs,
and it is up to UA implementation to support or not support all the possible values.
Comment 26 Masayuki Nakano [:masayuki] (Mozilla Japan) (working slowly due to injured) 2011-11-04 05:01:22 PDT
Hmm, I guess following code becomes to fail.

inputElement.value = "foo";
alert(inputElement.value);

Probably, the alert() doesn't show "foo" because during setting the value, we cannot dispatch textinput event. Therefore, we may not finish to modify the value at the second line. Is this OK??

I don't know why we block to dispatch a event if the code is called by another event handler even when the nested level isn't deep.
Comment 27 Masayuki Nakano [:masayuki] (Mozilla Japan) (working slowly due to injured) 2011-11-04 05:14:23 PDT
Oh, but according to D3E event spec, textinput is fired after the value is modified. This looks like same behavior as IE9. However, Chrome dispatches the events *before* actually modified. Therefore, on IE9, when I call preventDefault() of the textinput event, it doesn't prevent anything. On the other hand, on Chrome, it prevents the modification.

Which behavior should we implement?
Comment 28 Masayuki Nakano [:masayuki] (Mozilla Japan) (working slowly due to injured) 2011-11-04 05:19:56 PDT
I have been working on to implement Chrome's behavior. But it makes asynchronous modification due to script blocker. So, it's too hard for us. And it makes a lot of incompatibility with other browsers like comment 26.
Comment 29 Olli Pettay [:smaug] 2011-11-04 08:59:40 PDT
textinput is for the case when the input has already happened. IE9 does the right thing.
Comment 30 Masayuki Nakano [:masayuki] (Mozilla Japan) (working slowly due to injured) 2011-11-04 19:09:53 PDT
Okay, then, should it be cancelable? D3E said that it's cancelable but default action is none.
http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#event-type-textinput
Comment 31 Ojan Vafai 2011-11-04 19:18:07 PDT
(In reply to Olli Pettay [:smaug] from comment #25)
> textinput is a useful event and it can often be used instead of key and
> composition events.
> (input event is just a dummy notification event which happens after the
> 'input' has happened.)
> Using both input + textinput you can easily detect additions and deletions
> after they have actually
> happened - which is often desired.

I didn't realize that textInput is specced as happening after the dom has been modified. Hopefully WebKit can change that without compat problems (hopefully we can just kill the event!).

Regardless, if it fires after the dom has been modified, then does it fire before or after the input event? Couldn't you just put a "data" property on the input event that is the text inserted? Then you wouldn't need a whole other event and you get all the benefits of textInput. 

If there were cases that textInput fired where input did not fire, I could buy the argument for needing a textInput event. But input + data/inputMethod properties is a strict superset of textInput.

The fewer events we fire on each keypress the better.

> The supported inputMethods depends ofc the context where browser runs,
> and it is up to UA implementation to support or not support all the possible
> values.

I don't see anything in the spec indicating that these are optional values. I'd rather we remove from the spec the values that no UA intends to implement.
Comment 32 Masayuki Nakano [:masayuki] (Mozilla Japan) (working slowly due to injured) 2011-11-07 00:51:11 PST
Smaug:

Do you know the purpose of DOM_INPUT_METHOD_OPTION? When user chooses an item from autocomplete list, should we use it? And also when user chooses an item of suggested list of spellchecker?

And should we use DOM_INPUT_METHOD_UNKNOWN for inserting text from accessible, undo and redo?
# IE9 hangs up when I test undo and redo...
Comment 33 Olli Pettay [:smaug] 2011-11-08 02:18:05 PST
(In reply to Ojan Vafai from comment #31)
> I didn't realize that textInput is specced as happening after the dom has
> been modified. 
Argh, I'm wrong. Per spec textinput fires between keypress and keyup, but before the default actions,
so before DOM is modified.

> Hopefully WebKit can change that without compat problems
> (hopefully we can just kill the event!).
Webkit doesn't support textinput, but older, and now removed textInput ;)


HTML spec has very buggy definition for input event. I'll file a spec bug.
Comment 34 Masayuki Nakano [:masayuki] (Mozilla Japan) (working slowly due to injured) 2011-11-08 16:59:04 PST
(In reply to Olli Pettay [:smaug] from comment #33)
> (In reply to Ojan Vafai from comment #31)
> > I didn't realize that textInput is specced as happening after the dom has
> > been modified. 
> Argh, I'm wrong. Per spec textinput fires between keypress and keyup, but
> before the default actions,
> so before DOM is modified.

Then, the asynchronous modification is back since textinput event may be fired asynchronously when it's not safe to be fired. And we need to fix bug 698949 first.
Comment 35 Masayuki Nakano [:masayuki] (Mozilla Japan) (working slowly due to injured) 2012-01-13 04:34:05 PST
Created attachment 588374 [details]
testcase
Comment 36 Masayuki Nakano [:masayuki] (Mozilla Japan) (working slowly due to injured) 2012-03-20 04:00:08 PDT
-> INVA

textinput event has gone from D3E. Use HTML5 input event if you want to catch the timing of content changed. If you need to know the timing immediately before content changed, D3E or D4E should define beforeinput or something. If you need to know the input source, the input event should have the attribute.
Comment 38 Masayuki Nakano [:masayuki] (Mozilla Japan) (working slowly due to injured) 2012-03-27 20:33:16 PDT
I documented in MDN that textinput was removed from the spec.
https://developer.mozilla.org/en/DOM/DOM_event_reference
Comment 39 support 2013-05-17 22:19:29 PDT
Firefox has to implement this event or make dramatic change on compositionstart and compositionend. 

textInput event is basically same as the composition event, but Firefox's implementation of composition event is basically same as the input event which is unusable. 

For example, if user enter "bad" in IME, IME may show "bad" and "badly" as options, if user choose "badly", Firefox will generate following composition event:

compositionstart:
compositionend:b

compositionstart:b
compositionend:

compositionstart:b
compositionend:ba

compositionstart:ba
compositionend:

compositionstart:ba
compositionend:bad

compositionstart:bad
compositionend:

compositionstart:bad
compositionend:badly

As a programmer, how can you tell what the user entered. The correct composition event should be:

compositionstart:
compositionend:badly

Basically, if you want make the composition event works right, you'll have to implement this event. In my opinion, textInput is better way compared with composition event, because textInput can be use no both IME or non-IME environment which is very developer friendly.
Comment 40 Joe Eagar 2013-08-11 10:35:04 PDT
Why is it assumed that the only people who need unicode text input are writing HTML text editors?  What if one simply needs unicode input events?  The input event does nothing for you in that case.  The composition events help, but do they cover all cases?  For example, would a combination of keypress and composition events be able to handle non-latin keyboards?

Note You need to log in before you can comment on or make changes to this bug.