Bug 42805 – TextEvent should have inputMode property

• Component: DOM
• Status: RESOLVED WONTFIX

[Hajime Morrita]

DOM Level3 standard defines inputMode property on TextEvent object.
http://www.w3.org/TR/DOM-Level-3-Events/#events-textevents
So we should have it.

[Alexey Proskuryakov]

Hmm. Is there any way we could possibly implement it?

[Hajime Morrita]

Created attachment 62370 [details]
Patch

[Hajime Morrita]

> Hmm. Is there any way we could possibly implement it?
Sure, there is some limitation actually because our browsers has no way to 
distinguish voice/hand-writing based input from normal IME-based input like kotoeri.
I'm doing this because we have a plan to fire textInput event for pasting and dropping,
and we would like to distinguish them from key input / ime input.

[Alexey Proskuryakov]

I don't see how such a distinction makes sense. Specifically, on a Mac there is no way to tell that input comes from an input method (a custom key binding can send insertText: just as well).

What is the high level goal here? Maybe it can be achieved in a different way.

[Hajime Morrita]

Thank you sharing your thought.
> I don't see how such a distinction makes sense. Specifically, on a Mac there is no way to tell that input comes from an input method (a custom key binding can send insertText: just as well).
> 
> What is the high level goal here? Maybe it can be achieved in a different way.
One of our goal is to support rich-text editor implementation 
and to do so, we'd like to provide a way to hook text inputs that is allowed by WebKit currently, 
i.e. pasting and dropping. 
Because pasting/dropping would have HTML fragment, it might be helpful to 
distinguish them from  plain text input.

(BTW, the standard says nothing how we should handle such HTML fragment in TextEvent.data property
so we need discuss it anyway.)

[Alexey Proskuryakov]

Comment on attachment 62370 [details]
Patch

Pasting and dropping can be distinguished from other input - in fact, we already have such a distinction, see EditorInsertAction.h in WebCore. We don't expose that to JS code as far as I know, and it may be useful indeed.

However, please note that text added via insertText: can also be styled - the caller can always pass an NSAttributedString there.

I'm marking the patch r-, as I don't see why we would want to expose all the other options currently in DOM 3 events.

[Hajime Morrita]

Hi, thank you for taking a look!

> Pasting and dropping can be distinguished from other input - in fact, we already have such a distinction, see EditorInsertAction.h in WebCore. We don't expose that to JS code as far as I know, and it may be useful indeed.
Sure, we'd like to distinguish them from JS world because our goal is
implementing rich text editors in JavaScript. So distinguish them in WebCore isn't enough.
Thank you for letting me know. I should refer there to add paste/drop events.

> 
> However, please note that text added via insertText: can also be styled - the caller can always pass an NSAttributedString there.
Wow, I didn't notice tha so I'm taking a look. 
It looks that current implementation only handles a specific type of attributed string
that is given by an IME implementation (according to a comment there).
So It looks we don't need to handle a generic case.
(What I checked is [WebHTMLView insertText].)

> 
> I'm marking the patch r-, as I don't see why we would want to expose all the other options currently in DOM 3 events.
OK. I'll ask some webdev people what they exactly want.
And try to add pasting/dropping event at first, which are required anyway.

[Ojan Vafai]

> > I'm marking the patch r-, as I don't see why we would want to expose all the other options currently in DOM 3 events.
> OK. I'll ask some webdev people what they exactly want.
> And try to add pasting/dropping event at first, which are required anyway.

I agree with Alexey, the other inputModes are not very useful and likely hard to implement. I think we should go ahead just with paste and drop. We should also make a proposal for more reasonable list of inputModes, but we should wait until the current discussion on www-dom about converting textInput to beforeInput is resolved since that greatly affects what should go on that list.

[Hajime Morrita]

Closing this since DOM3 evolution is fading out and DOM4 is coming. 
And we don't have any consensus to implement this.

Someone may reopen this when there is clear demand for the feature.