tracking-fennec: --- → ?
tracking-p11: --- → ?
tracking-p11: ? → +
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. )
Quick notes: this looks like the code path ...  http://mxr.mozilla.org/mozilla-central/source/dom/html/nsTextEditorState.cpp?rev=6d79c472fe57#1916  http://mxr.mozilla.org/mozilla-central/source/dom/html/nsTextEditorState.cpp?rev=6d79c472fe57&mark=1992-1993#1966  http://mxr.mozilla.org/mozilla-central/source/layout/forms/nsTextControlFrame.cpp?rev=41c005e9398e&mark=854-855#822  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)
Assignee: nobody → nchen
tracking-fennec: ? → +
Poking a little deeper, it looks like this behaviour was intentionally added  . Note the example execution of the original attached test case . 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.  http://mxr.mozilla.org/mozilla-central/source/editor/libeditor/nsTextEditRules.cpp?rev=b9b8b65be80a&mark=732-732#728  https://bugzilla.mozilla.org/page.cgi?id=splinter.html&bug=1162818&attachment=8615087  https://www.dropbox.com/s/k8wl834mxctf51r/bug1170603.mp4?dl=0
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
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.