1170603 - IME composition not terminated when an input's value is set by JavaScript

Status: RESOLVED DUPLICATE of bug 549674

(Firefox for Android Graveyard :: Keyboards and IME, defect)

Description

[Hallvord R. M. Steen [:hallvors]]

Attachment: wc1170.htm

This was first reported in https://webcompat.com/issues/1170

To reproduce: go to Google JP, enable Japanese IME and input a string (for example 'なつ'). Google Suggest will kick in and offer a number of suggestions.

Next to each suggestions (to the right) is an arrow pointing upwards to the left - tapping it basically means 'insert this suggestion into the field but keep typing, don't search immediately'. Tap the tilted arrow for one of the suggestions.

Expected: the value you've typed in should disappear, the value you selected should appear, and the cursor should move to the end of the text.

Observed behaviour: you end up in some weird mode where the IME is still trying to compose a string, the cursor refuses to go to the end of the text, and the characters you were inputing will REPLACE as many characters at the start of the string Google inserted.

This seems like a Gecko bug. The issue: what should happen if JavaScript changes the value of a field during IME composition? See attached TC for a very simple demo.

In Chrome, when .value is set during composition the IME is interrupted. In Gecko it isn't.

Comment 1

[Mark Capella [:capella]]

Chrome, Opera, and generic Browser all seem to behave as mentioned above, using standard english, and a keyboard that supports auto-suggest such as Switft-Keyboard.

(It's a little difficult to be sure, as none of those browsers support suggest visual-hint styling / underlining of composition text. )

Comment 2

[Mark Capella [:capella]]

Quick notes: this looks like the code path ...

[0] http://mxr.mozilla.org/mozilla-central/source/dom/html/nsTextEditorState.cpp?rev=6d79c472fe57#1916
[1] http://mxr.mozilla.org/mozilla-central/source/dom/html/nsTextEditorState.cpp?rev=6d79c472fe57&mark=1992-1993#1966
[2] http://mxr.mozilla.org/mozilla-central/source/layout/forms/nsTextControlFrame.cpp?rev=41c005e9398e&mark=854-855#822
[3] http://mxr.mozilla.org/mozilla-central/source/layout/forms/nsTextControlFrame.cpp?rev=41c005e9398e#735

fyi, a naive hack in that final method to simply call imeSupport->ForceCompositionEnd() isn't enough to solve ... reading a little deeper ...

(also cc: jchen as possibly interested)

Comment 3

[Mark Capella [:capella]]

Poking a little deeper, it looks like this behaviour was intentionally added [0] [1].

Note the example execution of the original attached test case [2].

The composition text / nsISelectionController::SELECTION_IME_CONVERTEDTEXT is being replaced which is confusing.

In addition, at the end of the video, after the wrong text is populated into the <input>, tapping a single keyboard character 'y' drops the text added by the script and inserts the 'y', like the script text composition wasn't really committed.


[0] http://mxr.mozilla.org/mozilla-central/source/editor/libeditor/nsTextEditRules.cpp?rev=b9b8b65be80a&mark=732-732#728
[1] https://bugzilla.mozilla.org/page.cgi?id=splinter.html&bug=1162818&attachment=8615087

[2] https://www.dropbox.com/s/k8wl834mxctf51r/bug1170603.mp4?dl=0

Comment 4

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

The selOffset is almost always ignored by InsertTextImpl() and InsertTextIntoTextNodeImpl() during composition. When composition is started or restarted after reframed, it's referred.

Looks like this is a dup of bug 549674. I guess that Android widget does something hacky and that hid this issue...

Comment 5

[Mark Capella [:capella]]

The patch just landed for bug 549674 seems to solve this  \o/

Comment 6

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to Mark Capella [:capella] from comment #5)
> The patch just landed for bug 549674 seems to solve this  \o/

Thank you for the confirmation!