Re: explanatory note: preventDefault, IME & keyboard input

What I'd recommend for your problem is that you should simply let IME
inserts composition string and ignore that, because by definition (at least
theoretically) all composition strings are either to be removed or
committed.

When committed, it's a normal text typing operation. You can
preventDefault, create <ins>, and re-insert.

It is the normal IME operation flow to remove composition string on
commits, but maybe browsers may not tell JS that composition strings are
removed and committed strings are inserted, because browsers (and probably
most apps that do inline composition operations) may optimize it by just
changing attributes of composition strings.

I think we can make sure this optimization is disabled if event listeners
exist (or opted-in by a new function), and give JS an opportunity to handle
committed text just the same way as inputs from hardware keyboard.

Does this solve your problem?

/koji

On Fri, Oct 16, 2015 at 4:09 PM, Johannes Wilm <johannes@fiduswriter.org>
wrote:

> Hey,
> there seem to recently been have some confusion about IME and whether
> allowing preventDefault on IME-based beforeInput events would mainly be
> used to disable IME-input.
>
> *What is the current situation?*
>
> Let me exemplify with ICE -- the track changes plugin that is
> contentEditable based [1]. I contributed a great deal on getting it to work
> on Chrome a few years ago. It listens to keypress/keyup/keydown events and
> preventDefaults these under certain circumstances [2]. But why?
>
> Say you have a normal non-tracked text:
>
> "Hello this is a te|t text"
>
> | = caret
>
>
> There is an 's' missing where the caret is, and the user wants to insert
> it. If we don't preventDefault anything, it will turn into:
>
> "Hello, this is a test text"
>
> but because we track changes, we need to turn it into:
>
> "Hello, this is a te<ins>s</ins>t text." (simplified)
>
> We can't really create the <ins>-element before the user actually hits a
> key, because unless the user actually enters a letter, we cannot just add a
> random element there just because the caret is there.
>
>
> *What will the situation look like with our spec?*
>
> Once our beforeEdit/beforeInput command is available, for keyboard input
> we will listen to that instead of the keypress event. The above example
> will therefore work almost the same.
>
>
> How about if the s came from IME-input? The current state of negotiations
> is that the beforeInput event can be cancelled for every event EXCEPT those
> based on IME-input. Additionally, the discussion in the uievents thread
> show that we are not even allowed to sandbox IME input.
>
>
> The problem at hand would be that it would immediately enter the s without
> us being able to stop it:
>
> "Hello, this is a test text"
>
> We would then need to have saved a previous version of the DOM and a diff
> finding function on the two versions, find out that the difference is the
> "s" and then create an <ins>-element in it's place and exchange the current
> text for:
>
> "Hello, this is a te<ins>s</ins>t text."
>
>
> And this is just the first problem. The way Android/iOS handle what they
> see as "words" probably means that they will randomly remove <ins>-elements
> entirely or put entire words inside of <ins>-elements.
>
> *So what am I proposing?*
>
> I am proposing that also IME-based beforeInput events should be
> preventDefaultable, as a first step to making it easier to handle them.
>
> Additionally, if IMEs work on more than just simple text nodes, we
> probably both need a way to tell the browser what it should consider an
> entire word, and preferably also a way to sandbox them (which btw is really
> easy for keyboard-based input).
>
> I recognize Ryosuke's answer that the JS then also need to tell the
> browser after a browser handled text insertion what range it should
> consider as having been input by the user in order to both
>
> a) Continue IME-composition , underlining everything correctly.
>
> b) Let the browser know which parts of the text are still in need of spell
> checking/autofixing and which parts should be considered as having been
> edited by the user.
>
>
>
> ------
>
> Did that make it clearer?
>
> ------
>
> [1] https://github.com/NYTimes/ice/
> [2] https://github.com/NYTimes/ice/blob/master/src/ice.js#L1633
> --
> Johannes Wilm
> Fidus Writer
> http://www.fiduswriter.org
>