Re: exposing underlining mechanism for IME?

On Fri, Nov 6, 2015 at 8:21 AM, David Young <dyoung@pobox.com> wrote:

> On Fri, Nov 06, 2015 at 07:32:58AM +0100, Johannes Wilm wrote:
> > Hey,
> > looking at some files around IME in blink's source code. The code for
> > markers (spelling, composition) looks interesting. Are there security
> > concerns that make us not expose those to JS? If so, what concerns are
> > those?
> >
> > It seems like the main problem problem for IME is figuring out what is a
> > candidate text (what is underlined), what is committed. Candidate text is
> > already part of the DOM, so for us who look at the DOM from the
> perspective
> > of JavaScript, it makes it all really difficult to deal with, and for
> those
> > working in the browser world everything is getting more complex when we
> try
> > to do anything unpredicted in JS because you then need to make sure that
> > your underlining mechanism works correctly.
> >
> > But what if we exposed something like
> >
> > addCompositionMarker(range,color,thickness,backgroundColor)
>
> Say that the editor's author decides that underline and thickness do not
> apply?


I am not sure what you mean by that. The options "color", "thickness" and
"backgroundColor" seem to be the variables used in the browser, so they
must be enough to express all types of markers that IMEs may possibly want
to use.

So in contentEditable=events, where the editor JS will be responsible for
inserting every character into the DOM himself, the editor JS would simply
have to make sure that after entering the character, it will also mark
(underline) that character.

The editor JS then has two choices: use the default settings by the current
IME for color, thickness and background color, or specify his/her own. We
don't tell the JS anything about what the default values are, because that
could give the JS more information about the system it is running on (type
"Ah, I am underlining in brown in 0.2px, so most likely I am in Taiwan")
which could be a security concern.



> Is something like this not possible, where the editor JavaScript
> would activate the composition style on the composition-start event, and
> deactivate the style when the -end event arrived?
>
> Example 1: enter a "naked" accent
>
>         user key commands               JavaScript events
>         -----------------               -----------------
>         Option-E
>                                         composition start
>                                         insert ´
>         E
>                                         delete backward 1
>                                         insert é
>                                         composition end
>
> Example 2: enter accented e (é)
>
>         user key commands               JavaScript events
>         -----------------               -----------------
>         Option-E
>                                         composition start
>                                         insert ´
>         Space bar
>                                         composition end
>
>
It seems like the actions you mention would give the opposite result (1
would give "é" and 2 would give "´"), right?


 So the way you would handle those in cE=events would be:

1. compositionstart event. JS registers this and knows it will add markers
to everything until the compositionend event.

2. beforeInput{editType: insertCharacter, isComposition: true, data : '´'}
event. JS inserts the accent into the DOM where it wants, then marks the
character using addCompositionMarker.

3. compositionend event. JS decides the DOM is fine as it is and it removes
the composition marker by running something like
deleteCompositionMarker(range) over the characters that came out of the
composition.


For Google Docs this should also solve the problem of not being able to do
compositions across line breaks. Also, we noticed that Google Docs at times
underlines half characters. I am assuming that is because it is trying to
do its own marking mechanism in JS and fails at that. If it could just tell
the browser to mark arbitrary text nodes , then that would solve it, right?


But maybe there are some other security concerns that I haven't thought of?

Dave
>
> --
> David Young
> dyoung@pobox.com    Urbana, IL    (217) 721-9981
>
>


-- 
Johannes Wilm
Fidus Writer
http://www.fiduswriter.org