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

RESOLVED DUPLICATE of bug 549674

Status

()

RESOLVED DUPLICATE of bug 549674
3 years ago
3 years ago

People

(Reporter: hsteen, Assigned: jchen)

Tracking

unspecified
Points:
---

Firefox Tracking Flags

(p11+, fennec41+)

Details

(Whiteboard: [compat], URL)

Attachments

(1 attachment)

(Reporter)

Description

3 years ago
Created attachment 8614114 [details]
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.
tracking-fennec: --- → ?
tracking-p11: --- → ?
tracking-p11: ? → +
Whiteboard: [compat]
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. )
Assignee: nobody → nchen
tracking-fennec: ? → +
tracking-fennec: + → 41+
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
Flags: needinfo?(masayuki)
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...
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Flags: needinfo?(masayuki)
Resolution: --- → DUPLICATE
Duplicate of bug: 549674
The patch just landed for bug 549674 seems to solve this  \o/
(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!
You need to log in before you can comment on or make changes to this bug.