Re: [uievents] specify how compositionend works if the caret has been moved to a different element (#5)

>> Secondly, the spec reads "Event.target: focused element processing the composition".

> It should be a bug of UI Events.

What do you mean? Do you mean that the UI Events spec should be changed? Or that Firefox has a bug? 

> > That is what Chrome/Safari do, while for Firefox the Event.target is the element that was focused BEFORE the composition started.

> In these days, modern IMEs queries content information before compositionstart. Therefore, moving focus at compositionstart is too late for native IMEs.

What are modern IMEs for you and what are native IMEs? I tried this on Chrome on Mac OS X with one of the Mac OS X built-in IMEs, and the Chrome example still works, which means that it's no problem to move the focus somewhere else during compositionstart for Chrome on Mac OS X. Also Safari is able to move the focus during compositionstart.

If there are UAs which start composition before compositionstart and therefore cannot move the selection somewhere else, I would say that those UAs have a bug and should be fixed.

>> Firefox moves the caret to a different element and inserts no characters there by default. If the JS inserts the characters by means of execCommand/insertHTML, the endComposition event is triggered a second time.
> I think that if the focused element was \<input> or \<textarea>, the composition string is committed on the element at moving focus?

> IIRC, if it's a contenteditable element, it doesn't work fine due to our editor's bug (and it's very difficult to fix in current design...)

Could you guys look at the two pieces of example code I put together? :) 

And what is "our editor's bug"?

\<input> and \<textarea> do not matter much to us right now. In the Editing taskforce we are trying to fix editing in the browser, and having this work correctly is a key component.



---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/uievents/issues/5#issuecomment-137340844

Received on Thursday, 3 September 2015 05:41:09 UTC